采用流式并行架構處理數據幀的優化方法?

楊成林 周 勛 嚴新榮

（中國船舶集團有限公司第七二二研究所 武漢 430205）

1 引言

通信行業蓬勃發展，在保障安全性的前提下，數據處理速度逐漸成為影響用戶體驗的重要因素。采用軟件方式實現數據解析處理已經非常成熟，隨著業界對性能要求的不斷提高，在FPGA 上實現數據處理得到廣泛關注，如報文解析、數據加解密，以及通信系統中的各類接口控制等。

本文針對用于處理以太網口、串口等多種通信接口業務數據加解密功能的常規邏輯架構，對其不足提出了優化方案，在不影響業務準確性、時效性的前提下，采用數據幀流式傳輸與并行處理，重要業務優先級仲裁［1］，加密算法資源動態分配等方式提高加解密速度，并采用仿真測試對比優化前后的處理效率。

2 邏輯架構問題分析

2.1 功能需求

FPGA 邏輯用于解析以太網口、串口［2～3］等多種接口傳輸的數據幀，對業務幀、指令幀等不同報文采用加解密處理、參數配置、優先讀取等各種處理方式，實現報文解析重組轉發功能。

整體邏輯架構劃分為三個部分：業務處理模塊（包含幀格式解析與數據加解密等功能）、數據收發模塊、數據緩存模塊。數據收發模塊負責將上位機發來的報文寫入數據緩存模塊，并將接收完成的信號送給業務處理模塊，業務處理模塊主動從緩存區域讀取數據幀，并對數據幀中關鍵字節進行解析，模塊進入對應的狀態機，最終根據協議需求選擇指定的接口送出。

為了提高處理性能，減輕CPU 負擔，實現資源合理利用，選擇采用FPGA 承擔報文解析與數據加解密功能。

2.2 問題分析

2.2.1 占用鎖死工作模式

圖1的業務處理過程記為工程A。

圖1 邏輯模塊整體架構

各個收發模塊之間采用了“啟動-占用-釋放-再啟動”的占用鎖死工作模式，某一方進入工作態時，其余接口的業務功能全部暫停，等待先占用者釋放資源。占用/釋放信號lock/unlock 不僅鎖死了業務處理模塊，同時也會禁止自己接收新的數據幀，這就導致突發大量數據幀傳輸時，產生丟包問題。圖2簡要展示占用鎖死工作模式。

圖2 占用鎖死工作模式

業務處理模塊占用式方法處理業務優先級問題，承載數據幀解析重組、加解密運算、報文轉發優先級判定等重要功能。圖3 以并行架構描述業務處理流程，但實際上狀態機在跳轉回IDLE 狀態之前的過程中，不會從IDLE 再次接收信號進入業務啟動狀態，整個業務模塊是一個偽并行處理過程，威脅傳輸可靠性。

圖3 業務處理流程

圖4 ECB算法加解密圖解

圖5 CBC算法加解密圖解

2.2.2 算法介紹［4～5］

需要加解密的報文分為兩類，分別采用ECB或CBC［6］模式。由于工程A的仲裁方式每次僅允許一項業務進入業務模塊，所以一個算法核即可滿足業務需求。

1）ECB模式中，明文分組加密之后的結果直接成為密文分組。各個分組之間的加解密關聯較小，無順序要求。該種方式簡單快速，且支持并行計算。

2）CBC模式中，首先將明文分組與前一個密文分組進行異或運算，再進行加密。與ECB 模式相比，CBC加密模式的每一個分組均與其之前的所有分組相關，CBC解密模式的每一個分組僅與其對應的密文分組和前一個密文分組相關。

符號含義：

ENC：加密運算DEC：解密運算

C：密文分組⊕：異或運算

P：明文分組K：密鑰IV：初始化向量

3 優化方法

針對工程A 中存在的丟包與偽并行問題進行優化，優化后的圖6業務處理過程記為工程B，以實現合理分配FPGA 資源、功能模塊化、流式傳輸數據幀、并行加解密等目標。

圖6 邏輯模塊優化調整

3.1 收發模塊資源調整

2.2.1 節中提及占用鎖死的接收模式難以應對網口的突發大量傳輸，會產生丟包現象，而收發模塊僅起到緩存數據幀的作用，無需對數據幀進行處理。因此將原來IP 核由RAM 改為FIFO［7］，并采用AXIS 格式進行傳輸，擴充緩存空間［8］，應對來自高速接口的突發傳輸。

3.2 業務模塊處理流程優化

針對“啟動-占用-釋放-再啟動”的工作模式導致業務處理效率低下的現象，改變這種偽并行的工作模式，將原來的業務模塊細化為多個子業務模塊，并行處理業務。在業務部分之前添加一個分流模塊，將業務分類從業務處理模塊中剝離，對收到的數據幀進行預處理，簡化后續處理流程。具體設計如下：

1）業務模塊細化

將各類接口的業務分開，而非集中在同一個模塊的狀態機里。對于不同需求的業務模塊增加相應的功能結構，有針對性地提高效率與可靠性。如網口之間的ping 包，無需解析重組，可以直接發往目標網口，大大提高該類業務的處理速度［9］；對于需要進行加解密過程的業務，可在加解密模塊外部套一層異步FIFO［10］，通過改變FIFO 的讀寫時鐘頻率，均衡加解密速率與數據傳輸速率，實現數據在不同時鐘域［11～12］之間的可靠傳輸。

2）構建分流模塊與合流模塊

工程A 中的業務區分與業務處理功能都放在業務模塊中，各種業務搶占狀態機，導致偽并行邏輯。在業務處理模塊之前添加一個分流模塊，代替了前文提到的仲裁功能，真正實現偽并發到真并發的轉變。該模塊將收到的數據以AXIS格式并發送入所有的子業務模塊，但僅有業務相關一路的有效信號會被拉高。

業務并行處理結束時，存在多個業務同時準備從接口發出的情況，需要在合流模塊中進行發送順序仲裁。對于同一優先級的業務，采用先結束先發出的處理方式，由于發送數據速度較快，不存在堵塞現象；對于特殊業務，合流模塊會讀取到高優先級指令字，等待高優先級業務發送完后，再繼續發送普通業務。

3）算法核復用優化

針對ECB 與CBC 模式不同的加密原理，對二者分別適配單業務多算法核與多業務多算法核的調用方式，并采用“專用部分等待，公用部分搶占”的仲裁［13］方式，來提高加解密運算速率和算法核利用率。

4 仿真驗證及性能分析

工程A 和工程B 分別在modelsim 中進行仿真調試，并在國產開發環境pango2020.3 上進行編譯與測試，仿真采用以下兩種業務類型：

業務a：需要CBC模式解密的數據幀；

業務b：需要ECB模式解密的數據幀。

測試結果如圖7～圖11 所示，數據對比見表1。

表1 優化性能測試記錄表

圖7 工程A連續處理CBC業務丟包現象仿真圖

圖8 工程B連續處理CBC業務仿真圖

圖9 工程A時延處理CBC業務仿真圖

圖10 工程A連續處理ECB業務丟包現象仿真圖

圖11 工程B連續處理ECB業務仿真圖

經過上述仿真結果對比，計算得出以下結論：

1）通過更改占用鎖死機制，解決了工程A 在接收連續業務時的丟包問題。

2）在處理單個CBC 解密業務的情況下，工程B與工程A 性能基本持平，每幀開銷均為11.0μs；在處理連續CBC 解密業務的情況下，工程B 比工程A效率提升最高約11.04μs/ 1.84μs = 600%，即工程B中最多可實現6路并行處理。

3）在處理單個ECB 解密業務的情況下，工程B多次復用算法核對數據分組并行解密，處理效率比工程A提升約46.12μs/13.72μs ≈264%；在處理連續ECB解密業務的情況下，工程B效率相對于工程A 提升約203%～410%（連續處理數量越多效率提升越高，最高可達410%）。

5 結語

本文針對常規的數據幀處理方法作出優化，解決了處理過程中的偽并行和丟包問題，通過細化業務模塊等方式減少了代碼中的冗余部分，使邏輯架構更加簡潔。創新地采用算法核復用，根據算法特點有針對性的進行算法調用過程優化。相較于工程A，工程B 提高了硬件資源利用率和業務處理速度，對于項目本身的性能提升有重要價值。