Vivado HLS推動協議處理系統蓬勃發展(上)

　　4 #pragma INTERFACE axis port=inData

　　5 #pragma INTERFACE axis port=outData

　　6

　　7 static stream> modOne2modTwo;

　　8 static stream> modTwo2modThree;

　　9

　　10 moduleOne(inData, modOne2modTwo);

　　11 moduleTwo(modOne2modTwo, modTwo2modThree);

　　12 moduleThree(modTwo2modThree, outData);

　　13 }

　　例1中的代碼用于創建頂層模塊函數，供調用所有其它子函數使用。頂層模塊函數使用兩個參數，均屬于“流”(stream)類(Vivado HLS庫中提供的模塊類之一)。流是一種HLS建模架構，代表準備以流方式交換的數據通過的接口。流可以實現為FIFO隊列或內存，也可以是一種能夠配合任何C++架構使用的模板類。在本例中，我們定義了一種稱為axiWord的數據結構(Struct)，如例2所示。

　　例2：定義流接口使用的C++ 結構

　　struct axiWord {
　　ap_uint<64> data;
　　ap_uint<8> strb;
　　ap_uint<1> last;
　　};

　　該struct用于定義AXI4-Stream接口的部分字段。Vivado HLS能自動支持此類接口，使用編譯指令(pragma)語句即可完成設定。編譯指令是對高層次綜合工具的指令，用于指導工具實現要求的結果。例1中第4行和第5行的編譯指令用于告知Vivado HLS這兩個指令(具體是頂層模塊的輸入和輸出端口)將使用AXI4-Stream接口。AXI4-Stream I/F包含兩個必備信號，分別是有效信號和就緒信號，但它們沒有包含在聲明的數據結構中。這是由于Vivado HLS AX4 I/F會在內部處理這些信號，也就是說它們對用戶邏輯而言是透明的。如前文所述，在使用AXI4-Stream I/F時，從用戶處抽象流控制完全由Vivado HLS完成。

　　當然未必一定使用AXI4-Stream接口。Vivado HLS提供有豐富的總線接口。這里選擇AXI4-Stream作為常見標準接口的示例，供用戶進行包處理。

　　實現我們的設計的下一項工作是確保我們的三個模塊彼此互聯。這項工作也通過流完成，不過這次它們是位于頂層模塊的內部。第7行和第8行用于聲明實現這一目標的兩個流。這兩個流使用了另一種Vivado HLS結構ap_uint。這是一種無符號一維位陣列，隨后將按此對其操作。同時這也是又一種模板類，因此必須設定這個陣列的寬度。在本例中使用64位，與頂層模塊輸入輸出I/F的數據成員寬帶匹配。還有一點需要詳細說明的是這些流全部聲明為靜態變量。靜態變量是指其值不隨函數調用變化的一種變量。由于在作為順序C/C++程序執行時頂層模塊(以及全部的子模塊)每個時鐘周期會被調用一次，所以任何需要保持其值不隨時鐘周期變化的變量都需要聲明為靜態變量。

　　3 創建流水線設計

　　將要討論的最后也是最重要的一個是編譯指令。第2行中的數據流編譯指令指示Vivado HLS盡量以并行方式安排執行該函數的所有子函數。“internal”參數用于設置該模塊的初始化間隔(II)。初始化間隔(II)告知Vivado HLS該模塊必須具備的處理新輸入數據字的頻次，故決定了設計的吞吐量。不過這并不妨礙模塊內部的流水線化和擁有>1的時延。當II=2時，該模塊將用兩個周期完成數據字的處理，然后再讀入新的數據字。以這種方式Vivado HLS可以簡化模塊最終的RTL。也就是說，在一個典型的協議處理應用中，設計必須具備每個時鐘周期處理一個數據字的能力，故從現在起我們令II=1。

　　初始化間隔(II)告知Vivado HLS該模塊必須具備的處理新輸入數據字的頻次，故決定了設計的吞吐量。

　　最后要解決的問題是函數調用本身。在Vivado HLS中，這個過程對應的是模塊的實例化。傳遞給每個模塊的參數實質上定義了模塊的通信端口。在本例中，通過將輸入連接到第一個模塊，然后用 modOne2modTwo流把第一個模塊連接到第二個模塊，依次類推，將三個模塊鏈接起來。(未完待續)