HLS Stream案例分析

思考空間

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

圖11形參為stream的頂層函數(shù)

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

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

圖1 頭文件

圖2 read_data源代碼

圖3 handle_data源代碼

圖4 top源代碼

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

首先，執(zhí)行C功能仿真，仿真結束時會出現(xiàn)如圖5所示的warning。

圖5 C Simulation時出現(xiàn)的warning

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

圖6 修改FIFO深度

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

圖7 設置DATAFLOW

圖8 C綜合后顯示的warning

圖9 添加static關鍵字

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

圖10 C/RTLCosimulation錯誤信息

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

圖11 Array partition

至此，我們創(chuàng)建了3個Solution：

Solution1:設置FIFO深度

Solution2:設置FIFO深度 + 設置DATAFLOW

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

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

圖12 性能對比

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

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

-當流數(shù)據(jù)被綜合為FIFO時，由于默認深度為1，可能會在C/RTLCosimulation時出現(xiàn)DEADLOCK

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