思考空間

對于如圖11所示的頂層函數，HLS會將其接口綜合成何種形式？

圖11形參為stream的頂層函數

對于頂層函數，如果形參類型為hls::stream，HLS會將其綜合為ap_fifo類型的接口。

這里，我們看一個HLS Stream應用案例。頂層函數top由兩個底層函數read_data和handle_data構成，其中read_data主要功能是從輸入stream上獲取特定數據；handle_data的主要功能則是對獲取的數據進行處理。這里主要是為了說明stream的使用方法，所以，請大家把關注點放在stream的定義、函數之間的參數傳遞以及相應的directive的設置等。實際上，read_data和handle_data是可以合并的。

圖1 頭文件

圖2 read_data源代碼

圖3 handle_data源代碼

圖4 top源代碼

從圖2和圖3的代碼中可以看到，從流中讀取數據可以用>>或read()，向流中寫入數據可以用 << 或write()。同時，在使用 << 或 >> 時，并不需要添加#include 。

首先，執行C功能仿真，仿真結束時會出現如圖5所示的warning。

圖5 C Simulation時出現的warning

第二步，不設置任何directive，直接執行C綜合，此時會顯示如下錯誤信息。該信息表明，在非dataflow區域使用默認的FIFO規模（這個FIFO是因為stream而生成的，默認深度為1）,會導致Deadlock。根據提示我們修改這個FIFO的深度。之后，重新執行C綜合和C/RTL Cosimulation，均可通過。

圖6 修改FIFO深度

第三步，進一步優化，可以看到這兩個底層函數是可以應用dataflow以降低latency。具體設置如圖7所示。執行C綜合，綜合結束時會顯示如圖8所示信息。[HLS214-111]顯示靜態變量和非靜態Stream不能在同一個DATAFLOW區域中使用，故需要對top.cpp第4行進行修改，只需添加static關鍵字，如圖9所示。再次綜合，該warning即被消除。

圖7 設置DATAFLOW

圖8 C綜合后顯示的warning

圖9 添加static關鍵字

如果只設置DATAFLOW，而不設置FIFO深度，C綜合是可以通過的，但執行C/RTL Cosimulation時，會顯示如圖10所示錯誤信息。可以判斷與FIFO的讀寫相關。這通常是因為出現了FIFO寫滿或者FIFO讀空，從而造成DEADLOCK。從這個角度而言，先設置一個solution，不用進行任何directive的設置，執行C綜合，盡可能地修復所有的warning。這個階段給出的warning及修復建議更具體、更具有針對性。

圖10 C/RTLCosimulation錯誤信息

第四步，進一步優化，由于數組key深度只有8，可以完全打散，用register代替，具體設置如圖11所示。

圖11 Array partition

至此，我們創建了3個Solution：

Solution1:設置FIFO深度

Solution2:設置FIFO深度 + 設置DATAFLOW

Solution3:設置FIFO深度 + 設置DATAFLOW + ARRAY PARTITION

3個Solution綜合后的性能對比如圖12所示。

圖12 性能對比

從這個案例我們可以得出如下結論：

-流用于內部函數間的參數傳遞時，會被綜合為深度為1的FIFO

-當流數據被綜合為FIFO時，由于默認深度為1，可能會在C/RTLCosimulation時出現DEADLOCK

-先創建一個沒有任何directive的Solution執行C綜合，盡可能地解決此時出現的warning或者錯誤，這也是UFDM所倡導的設計思想。