有客戶反饋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）連接對應的引腳是會改變：

有了這個對應表，剩下來的事情就簡單了，只需要在Displayport一致性測試軟件中指定一下連接的lane就可以了，這樣測試出來的結果不管是Pass還是Fail都可以確定得到的結果是真實可信的。