FPGA跨時鐘域的數據傳輸糾錯協議優化方法

李建翔，李北國，楊玉華，劉東海

(1.中北大學儀器科學與動態測試教育部重點實驗室，山西 太原 030051；2.中北大學電子測試國家重點實驗室，山西 太原 030051；3.北京航天長征飛行器研究所，北京 100076)

0 引言

在信息技術飛速發展的今天，對數據傳輸的速率、傳輸距離、誤碼率提出了更高的要求，更加注重三方面的均衡[1]，不僅在航空航天領域，同樣在引信領域，越來越多型號設備涉及到高速數據的傳輸以及需要對其數據進行校驗，從而保證設備運行的可靠性及穩定性。

如今的測試測量任務中，尤其是惡劣環境中的測量，前人都已從硬件與軟件兩方面設計盡可能地降低數據傳輸的誤碼率，諸如解決信號在反射、串擾以及傳輸線損耗等方面的影響，在軟件中也加入許多校驗重傳算法以保證數據傳輸的可靠性[2]。文獻[2]從硬件軟件兩方面進行優化設計，采用8 B/10 B+CRC+ARQ重傳校驗的方式保證數據的可靠性，延長LVDS數據的傳輸距離。文獻[3]設計了一種片間通信校驗，經過多通道多輪校驗，完成數據對齊，補償由于外界干擾帶來的路間延遲，從而保證后續雙向通信可靠進行。目前常用的數據傳輸糾錯方法均采用在發送端進行數據編碼，接收端再對其進行校驗，同時還需要傳輸鏈路具備重傳糾錯功能，在數據出錯時及時向發送端反饋信息，重新傳輸正確的數據。然而目前的方法對于在跨時鐘域情況下導致的亞穩態問題并沒有解決，會造成重傳以及確認指令的觸發標志不能正確識別，從而引起數據傳輸錯誤。本文針對此問題，提出FPGA跨時鐘域的數據傳輸糾錯協議優化方法。

1 傳統傳輸糾錯協議

該傳輸協議已經運用于某型號采編存儲器以及與之相對應的地面綜合測控臺，采編存儲器主要功能是通過外部接口接收2路PCM數據，并將數據存儲于Flash芯片中，同時也能夠與綜合測控臺通過Hotlink接口進行通訊，遠距離傳輸采用光纖傳輸，即采編存儲器將接收到的數據打包發送給測控臺，對其數據進行分析判定。在具體的測試過程中，測控臺具備雙向RS422鏈路通信，通過RS422接口上行鏈路發送啟動記錄指令，控制采編器啟動記錄，同時采編存儲器將通過RS422接口下行鏈路返回工作狀態至測控臺，同時通過Hotlink接口將數據下發至測控臺，傳輸鏈路框圖如圖1所示。

圖1 硬件傳輸鏈路示意圖Fig.1 Schematic diagram of hardware transmission link

422指令采取三判二機制，如圖2所示，測控臺連續發送三次指令，采編存儲器若能識別到2次指令，便可執行該命令。在Hotlink鏈路發送數據的過程中，通過對數據進行CRC校驗以提高數據傳輸的可靠性[4]。數據的具體傳輸過程如下：采編存儲器在下發的每一包8 KB原始數據增加4 B的包頭，并對此8 KB數據進行CRC運算，將4 B的校驗字附在數據之后，此時形成8 200 B的數據，采編存儲器通過Hotlink接口將數據發送出去。在接收端，測控臺將再次計算所接收到的8 KB數據的CRC校驗字，將計算結果與接收到的CRC校驗字比較，如果二者一致，則說明接收數據正確，將數據去除包頭和校驗字后發給上位機，并通過422接口發出確認指令；如校驗錯誤，則丟棄數據，并通過422接口發出重傳指令；若測控臺連續發送三次重傳指令，測控臺仍無法正確接收數據，則將當前數據發送給上位機軟件，給采編存儲器回復確認命令，并且開始下一包數據傳輸。以上所涉及返回的確認或者重傳指令是在下一包數據的8 100 B之后進行檢測，以決定是否重傳。

圖2 數據傳輸包格式Fig.2 Data transmission packet format

2 問題分析及優化方法

在經過大量的測試后，發現采編存儲器向地面測控臺下傳數據的過程中，出現了兩種類型的數據錯誤，對其作出歸納后，具體表現如下。

2.1 數據存在多8 KB無效數據的現象

在如圖3所標記的兩包8 KB數據中，兩包數據的前8 100個數據完全一致。同時第一包數據的第8 100個數之后出現4 B數據包頭標志和88個數據，此處的88個數據與第一包數據之前的8 KB數據中從1～88的數據內容完全一致，如圖4所示。

圖3 存在兩包數據完全一致Fig.3 There are two packets of data exactly the same

圖4 在8 100 B之后數據出現包標志Fig.4 The packet mark appears in the data after 8 100 B

2.2 數據中存在丟失16 KB數據的現象

如圖5所示，PCM2數據C8 BB 3F 5F和C8 BB 3F 5A之間丟失4 KB數據，PCM1數據C1 AA 9E 70和C1 AA 9E 63之間丟失12 KB數據，總共丟失16 KB數據。

圖5 數據中丟失16 KB數據Fig.5 16 KB data lost in data

2.3 問題分析

在數據包具體的傳輸過程中，如2.1節所闡述，數據發送端(采編存儲器)在發送完某包數據的前8 100個數據之后，數據接收端(測控臺)會檢測前一包數據是否需要重傳，此時只會出現兩種可能的結果，重傳或確認，不管是什么結果，均認為是前一包數據的結果。但是在異常情況下，此處的確認指令可能是前兩包數據的結果，前一包數據的結果未正常接收，或者是前一包數據的確認指令被新的重傳指令所覆蓋，因此會導致發送端發送的數據包不是接收端真正想要的，此時數據就會出現問題。在此種情況下，當接收端接收數據的過程中，只要識別到包頭5A 54 5A FE之后，就會開始接收數據，但是數據是否為接收端真正想要的數據，我們無從知曉，因此就會出現如上所述的兩種錯誤。

針對多8 KB無效數據的情況，當發送端(采編存儲器)將第A包數據重傳被正確接收后，應該下發確認指令，并且正常接收第B包的數據。假若此時該確認指令沒有被正常接收，當其發送B包數據至8 100 B時，識別到的仍然是上一次的重傳指令，則會繼續發送A包數據，此時則會出現數據為8 100 B的B數據+92 B的A數據，導致CRC校驗錯誤，如此往復重傳三次，接收端(測控臺)強制接收錯誤數據并發出確認指令，繼續發送B包數據，因此就會出現實際情況中B包數據前多出8 100 B B數據+92 B A數據的情況，分析過程如圖6所示。

圖6 多8 KB無效數據原因Fig.6 Reasons for 8 KB more invalid data

針對丟16 KB數據的情況，當接收端(測控臺)在接收A數據出現錯誤時，應該下發重傳指令，此時應延時1 000個時鐘重新識別包頭以接收正確數據，在此時間里，實際上已經跳過下一包B數據的包頭，等待A數據的包頭。但此時若發送端(采編存儲器)在發送B數據的8 100 B時沒有接收到重傳指令，仍然默認為上次的確認指令，因此會繼續發送C包數據，此時接收端則開始接收C包數據，從而丟失了前兩包數據，即問題所在，分析過程如圖7所示。

圖7 丟失16 KB數據原因Fig.7 Reasons for losing 16 KB data

從以上兩種錯誤數據傳輸的過程進行詳細分析，確定重傳以及確認指令的觸發標志存在異步時鐘域的影響，標志在20 MHz時鐘下產生，而在40 MHz時鐘下識別標志變化，因此當標志發生變化時，發出重傳或者確認指令，由于在40 MHz時鐘下僅同步一次，所以可能出現亞穩態現象，導致觸發標志變化未能正確識別[5]，最終出現了如上兩種錯誤。

近年來，FPGA作為軟件中極為重要的一環，特別是在控制、通信、圖像處理等關鍵設備中，且隨著功能越來越復雜，單時鐘域的FPGA已經逐漸不能滿足功能需求，因此多時鐘域的FPGA成為設計中不可缺失的一部分[6]。在不同的時鐘域之間進行數據交互，亞穩態的現象就不可避免[7]。觸發器在時鐘沿的驅動下進行數據的采集與更新，如果建立時間與保持時間不能滿足要求，使得觸發器不能按照預期實現翻轉，那么電路就會出現亞穩態，輸出電壓處于不正確的電平值，導致電路穩定輸出的時間不可預知，且可能會存在振蕩的風險[8]。

由跨時鐘域導致的亞穩態現象具有如下特點：1) 亞穩態是雙穩態電路固有的屬性，是我們不可避免的，同時依概率發生[9]，只能盡量減少其發生；2) 亞穩態的概率性及其對溫度的敏感，使其很難在測試與驗證中完全體現[10]；3) 亞穩態會導致后端邏輯得到的值存在差異，進而影響次級傳輸，使得整個系統的功能可能與預期存在較大差異[11]。

根據所存在的問題，以及對其進行分析的原因，數據傳輸協議主要從兩方面進行優化設計：

1) 標志判斷優化：由20 MHz時鐘下產生的重傳、確認觸發標志，在40 MHz時鐘域下同步兩次后再進行信號變化的判斷，確保測控臺的重傳或確認指令能成功發送至采編存儲器。

2) 接口協議優化：將422重傳及確認指令的末位修改為包計數，例如“12 3X”，其中X代表包計數，取值范圍為0～15。

2.4 發送端軟件優化

發送端更改內容主要為在對8 KB數據增加包頭時，在最后一位增加X，其取值范圍為0～15，每發送一包數據，包計數增加1；同時每當數據發送至8 100 B時，對其判斷是否需要重傳，若需要重傳，還需判定是重傳當前包數據還是上一包數據；若不需要重傳時，還需判斷所確認的包計數是否為當前發送包計數減1，若為1，則不需要重傳，繼續發送當前數據包，若不為1，則需要重新發送前一包數據。流程如圖8所示。

圖8 發送端數據傳輸優化Fig.8 Data transmission optimization at the sender

2.5 接收端軟件優化

接收端更改內容主要為當識別到下載指令信息有效后，開始識別包頭，同時解析出包計數X，若X等于receive_cnt，則繼續接收該包全部數據，同時根據數據計算出CRC校驗碼，將接收到的CRC校驗碼與計算的校驗碼相比較，若完全一致，則通過422接口向發送端發送該包數據的確認幀，反之則發送重傳幀。

若X等于receive_cnt-1，說明接收端未能正確接收前一包數據的確認幀，則通過422接口向發送端發送receive_cnt-1包的確認幀；若X等于receive_cnt+1，說明接收端未能接收receive_cnt包的重傳幀，則通過422接口發送receive_cnt包的重傳幀。若長時間未接收到數據包頭，導致錯誤計數達到27 576，則不斷向發送端發送該包數據的重傳幀，直到接收到正確的數據，流程如圖9所示。

圖9 接收端數據傳輸優化Fig.9 Receiver data transmission optimization

經優化后的數據包傳輸過程如圖10所示，對每一步驟可能出現的情況均進行了詳細的列舉。

圖10 優化后測控臺與采編存儲器之間數據包傳輸過程Fig.10 After optimization, the packet transmission process between the measurement and control platform and the acquisition and editing memory

3 實驗驗證與分析

對軟件更改后，同時在上位機界面單元測試的底部，增加了Hotlink鏈路錯誤計數和重傳計數兩個顯示窗口，便于更加直觀明了地觀察到數據傳輸是否出現錯誤以及錯誤計數，如圖11所示。

圖11 上位機界面圖Fig.11 Interface diagram of upper computer

通過實際測試，對接收到的數據進行解析，如圖12所示，為整包數據的測試結果。從圖中可以看出，包頭為“5A 54 FE”，其后為“FX”，“X”代表包計數，“X”的計數范圍為0～15，與協議一致，可以很清晰明了地看出數據包是否連續，以便定位到數據是否出現多數或者丟數現象。

圖12 數據包Fig.12 The packet

再次對PCM1的數據進行解析，如圖13所示，幀頭為“C1 AA”，經過傳輸的數據幀計數能夠依次遞增，沒有出現丟數多數現象，修改后的協議能夠解決所出現的問題。

圖13 PCM1數據Fig.13 PCM1 data

利用ISE軟件的ChipScope在線分析，對優化后的重傳協議進行測試，某次實際測試結果如圖14所示，當Error_flag_q為上升沿時開始進行重傳，此時幀頭為“5A 54 5A FF”，可以看出此時包計數為“E”，同時Retransmission_cnt開始重傳計數，實現預期重傳反饋功能。

圖14 實時重傳仿真Fig.14 Real-time retransmission simulation

經過多次測試，在Hotlink電纜為61.2 m(全部為粗纜)，重傳計數均為0，Hotlink鏈路錯誤計數均為0，傳輸速率約為6.4 MB/s，數據全部正確；Hotlink電纜為78.8 m(61.2 m粗纜和17.6 m細纜)，重傳計數為10～93，Hotlink鏈路錯誤計數為0，傳輸速率為約6.4 MB/s，數據全部正確；Hotlink電纜為90.8 m(61.2 m粗纜和29.6 m細纜)，重傳計數為2 000～8 000，Hotlink鏈路錯誤計數為0，傳輸速率為約6.33 MB/s，數據全部正確；在Hotlink電纜斷開又重新連接后，數據依然能正常傳輸，數據全部正確；在422電纜斷開又重新連接后，數據依然能正常傳輸，數據全部正確；在422和Hotlink電纜均斷開又重新連接后，數據依然能正常傳輸，數據全部正確。因此，改進后的傳輸協議具備更強的鏈路適應性。

4 結論

本文提出FPGA跨時鐘域的數據傳輸糾錯協議優化方法。該方法通過對標志判斷以及接口協議兩方面進行優化，以使接收端和發送端達到更好的交互，確保重傳或確認指令能成功發送，解決了由于跨時鐘域導致數據傳輸出錯的問題。仿真實驗驗證結果表明，優化后指令均能正確下發，數據傳輸錯誤計數均為0，數據全部正確，相較于傳統的協議更加穩定可靠，具備更強的鏈路適應性。