一、為什么要用Serdes

傳統(tǒng)的源同步傳輸，時鐘和數(shù)據(jù)分離。在速率比較低時（<1000M）,沒有問題。?

在速率越來越高時，這樣會有問題?

由于傳輸線的時延不一致和抖動存在，接收端不能正確的采樣數(shù)據(jù)，對不準眼圖中點。?
然后就想到了從數(shù)據(jù)里面恢復(fù)出時鐘去采樣數(shù)據(jù)，即CDR?

這樣就不存在延遲不一致的情況，有輕微的抖動也不會影響采樣（恢復(fù)的時鐘會隨著數(shù)據(jù)一起抖動）。

二 、為什么要用8b10b,64b66b?

1 提供足夠的跳變來恢復(fù)時鐘

這樣還有問題，收發(fā)兩端必須共地，但往往很難實現(xiàn)。?

于是采樣差分信號傳輸，為了防止共模電壓在接收端導(dǎo)致電流過大，使用電流驅(qū)動模式。看到接收端有電容進行交流耦合，隔直流。這樣又帶來一個問題，需要DC平衡。所以有了下面另一個原因。

2 DC平衡，即0和1的數(shù)量要相等。

3 run length，0和1連續(xù)出現(xiàn)的最大長度

AGC自動增益控制需要交流分量才能實現(xiàn)放大?

4 comma碼，K碼

在serdes上面的高速串行流在接收端需要重新串并轉(zhuǎn)化成多字并行，怎么找到字的邊界進行對齊呢？?

這就需要一個特殊的序列，這就是comma碼。?

傳輸過程中需要的一些控制，最好不要和數(shù)據(jù)沖突了，這就是K碼。

基于以上四個原因，就有了8b10b，64b66b的出現(xiàn)。

三 、8b10b編碼

8b10b編碼一句話概括起來就是把8bit的數(shù)據(jù)變成10bit的數(shù)據(jù)，其中所有1或0的個數(shù)不會超過6個，并且連續(xù)的1或0的個數(shù)不會超過4個。這樣原本1024的漢明空間編碼后就大大減小了。其中有256個data碼和12K碼控制碼。這樣數(shù)據(jù)和控制碼不會重合。?

其中K28.1，K28.5，K28.7可以作為分隔碼，也叫comma碼，用于接收端在串行的數(shù)據(jù)流中找到字節(jié)邊界。常用的K28.5即0xBC。因為正常傳輸?shù)臄?shù)據(jù)也可能有0xBC，怎么區(qū)分呢？是有一根單獨的控制線，tx_is_K在傳輸K碼時拉高，在傳數(shù)據(jù)時拉低，去控制8b10b的編碼模塊到底是編碼成數(shù)據(jù)還是控制K碼。

四、Xilinx Serdes的幾個細節(jié)

1.COMMA碼使用

K28.5,0xBC,+0101_111100,-1010_000011; 為檢測字節(jié)分割。?

使用其它K碼，作為幀開始，幀結(jié)束，時鐘修正和數(shù)據(jù)對齊。

2.多字節(jié)處理

在數(shù)據(jù)率比較高的時候，外部位寬可能是2字（16位）或者4字（32位）。這是如果收發(fā)雙方不約定好在高低哪個字發(fā)送comma碼，這時是可以檢測字邊界，但接收端就會出現(xiàn)高低字節(jié)翻轉(zhuǎn)的情況。在任意對于單COMMA的數(shù)據(jù)對齊，選擇偶數(shù)字節(jié)對齊。發(fā)送的時候 0x5ABC->2’b01。?

也可以選擇發(fā)送組合的comma碼，就是把NP的comma拼接起來發(fā)送，這樣接收端就檢測16bit的雙字邊界。也可以避免上面的情況出現(xiàn)。發(fā)送的時候0xBCBC->2’b11

注意：decode valid comma only不要選，因為還可能發(fā)送其他的K碼用于控制。反正8b10b是用的收發(fā)器硬核的資源，不用白不用。

3、環(huán)回設(shè)置：

1.“000”：正常模式?

2.“001”：近端PCS環(huán)回?

3.“010”：近端PMA環(huán)回?

4.“100”：遠端PMA環(huán)回?

5.“110”：遠端PCS環(huán)回?

注意Xilinx例化的example的文件中配置的環(huán)回是預(yù)留環(huán)回接口的意思，仍然需要另外手動配置。

4、fsm_down狀態(tài)機

在Monitor Data_Valid模塊，是用的frame_check的正確的信號，校驗失敗會導(dǎo)致復(fù)位GTrxreset?？梢圆挥眠@個反饋，直接置1。需要手動改一下。

編輯：黃飛

?