为什么Type C接口Displayport Interpair skew测量项不通过
有客户反馈DIsplayport HBR测试中Interpair skew的测量项目fail得比较异常，就是固定的某条lane与其他lane之间的测试值不通过，并且偏差很大，都到几十个UI了，并且固定在某个通道，但是又没有头绪为什么。
是否示波器及探头有问题呢
于是有意思的事情就来了，对于HBR的信号， 其信号速率是2.7Gbps，对应一个UI的宽度为370.3ps， 如果是如上图所示的40个UI，那对应的可就是370ps x 40 = 14.8ns，这个是远大于可能的示波器及外部探头可能的时延（通常几十ps就算大了）。这个情况第一时间就可以排除了。
Interpair skew的测试原理和方法
如果要找到问题的根源，那首先要从Displayport的Interpair skew的测试原理和方法入手。针对这个项目，一致性测试标准CTS是这么描述的：
既待测会发出来PRBS7的码型用于测试。并且DP标准定义了不同lane之间有递增的20UI的偏移，也就是说lane0 到lane2之间天生就有40UI的偏移。
根据这个定义就可以大概推断到，Interpair skew出现大于20UI的偏移是不大可能的，除非是lane的编号出现了错误。
利用示波器工具定位lane的编号错误
对于PRBS7的码型，要去找到不同lane之间对应边沿的时延，最好的方法就是找特征边沿。 PRBS7码型长度为27-1 = 127比特，最长的连1码型为7个比特，即正向脉宽约为7 x 370ps(UI) = 2.59ns。
于是我首先要确认发出来的码型确实是PRBS7，有两个方法：
■ 1. 通过光标去卡重复的最宽的两个方波之间（连续的7个“1”比特）的时间间隔，如下图， 如果是127个比特的重复码型，那么他们的间隔应该是370ps x 127 = 46.99ns。用光标看出来是46.9ns基本确认码型长度正确。
■ 2. 通过示波器的DPOJET软件中的DataRate确认码型：如下图，示波器可以很精确的得到波形长度是127个比特：
有了这些信息，就方便进一步的手动确认大概的interpair skew是多少了。这个可以通过示波器的Search功能实现。首先我在Analysis->Search菜单下面加入四个脉宽搜索（Width）条件分别对应4条Lane：
由于PRBS7码型的连1的最大宽度为2.59ns，所以我将脉宽搜索条件设定为2ns – 3ns之间：
在结果表以及示波器波形上就能清晰的看到这个最大脉宽特征码型的时间间隔以及图示：
如果按照一致性标准的要求，相邻的lane之间有20UI的偏移，即370ps x 20 = 7.4ns， 那么可以看到上图中不同颜色的标记代表了不同lane之间间隔还是存在依次递增的关系，并且时间差不过就在7.4ns左右。
于是破案了，这个测试结果出现几十UI的原因就是lane的定义与硬件连接不匹配！
TypeC口中针对Displayport之间的引脚定义
由于客户的待测是TypeC的接口以及Wilder Tech的测试治具，因此开始着重检查引脚定义与连接。
通过列表可以看到，Displayport在应用Alter Mode中与TypeC接口对应的连接定义是有差别的，因为正向插入（Normal Plug）和反向插入（Flipped Plug）连接对应的引脚是会改变：
USB TypeC 引脚定义 | Displayport Normal Plug | Displayport Flipped Plug |
A2 (TX1+) | Lane 2+ | Lane 1+ |
A3 (TX1-) | Lane 2- | Lane 1- |
A10 (RX2-) | Lane 0- | Lane 3- |
A11 (RX2+) | Lane 0+ | Lane 3+ |
B2 (TX2+) | Lane 1+ | Lane 2+ |
B3 (TX2-) | Lane 1- | Lane 2- |
B10 (RX1-) | Lane 3- | Lane 0- |
B11 (RX1+) | Lane 3+ | Lane 0+ |
有了这个对应表，剩下来的事情就简单了，只需要在Displayport一致性测试软件中指定一下连接的lane就可以了，这样测试出来的结果不管是Pass还是Fail都可以确定得到的结果是真实可信的。
关注官方微信
