在這個系列的前3篇文章“HighLevel Synthesis(HLS) 從一個最簡單的fir濾波器開始1-3”中，我們從一個最簡單的FIR濾波器，一步步優化，得到了一個比較理想的HLS綜合結果，資源消耗很少。我們先回顧下：

我們做過的優化主要有：
在頭文件定義中，把數據和系數的精度都改成了整形，用18bit來表示；
在fir.c的for loop里面，修改代碼結構，只顯性的出現一處乘法描述；
通過這2處改進，我們成功把DSP48E的消耗數量，從最開始的8個，降低到了1個。最新的資源消耗如下：

在這一章，讓我們從別的角度，繼續改進這個fir濾波器的性能。
僅從上述資源報告中DSP48E的消耗個數，我們就可以大致判斷出來，fir濾波器其rtl的實現方式，大致采用的是串行的處理方式。這種結構雖然資源消耗較少，但是處理時間和延遲卻比較長，這也可以從HLS的性能分析報告中得到印證：

從上面的報告中可以看出，其處理延遲Latency為33=2*16+1（一共16個循環，每個循環消耗2個clock cycle，所以一共是32個cycle，最后再+1表示最終輸出的時候還要再寄存一拍，所以總的延遲latency是33個clock cycle）。其處理的流程大致如下：

這個Latency=33的延遲有些偏大的，有沒有改進空間呢？其實是有的，讓我們還是回到代碼中，這里會給我們一些提示：

代碼中每個循環里面，需要做4件事情：
第一個是讀操作 read shift_reg[i-1]；
第二個是寫操作 write shift_ref[i]；
第三個是乘操作；
第四個是加法操作；
熟悉rtl代碼和硬件電路的童鞋應該可以分析，其實這3步操作，有可能可以包在一個大的組合邏輯電路里面，在1個時鐘周期里面完成！也就意味著，其處理數據流可以變成下面這個樣子，即每個for循環只需要消耗1個clock cycle即可：

那么如何才能實現上面的處理結構呢？
調整fir.c代碼本身的結構，無法給HLS編譯器傳遞這樣的信息，此時只能通過特定的語法約束，在tcl腳本里面告訴HLS編譯器，我需要把每個for循環的latency壓縮，從2個clock cycle/per for loop壓縮為1個clock cycle/perfor loop。此時我們會用到一個HLS PIPELINE II的約束，具體設置方法如下：

設置好后，我們點擊綜合按鈕，很快綜合結果就出來了，我們看下performance報告：

為什么latency仍然很大呢，不僅沒有縮小，反而還從33變成了34，是我們約束設置的不多嗎？不是的，我們約束設置的沒有問題。從標紅的地方可以看出來，我們的確告訴了HLS工具，把每個for loop的處理時間減小為1個clock cycle（target=1），只是HLS沒有實現我們的設定目標，綜合結果是2（achieved=2）。為什么HLS無法達成我們的設定目標呢，雖然從理論上分析它應該是可以的，一定有什么東西阻礙了這個優化過程。

這里留給讀者思考3分鐘……

接下來給出答案，其實問題出在shift_reg上，是它限制了latency的優化：

在綜合資源報告里面，我們可以看到有一塊用LUT實現的RAM（所謂的distributedRAM），它其實對應的c代碼原型是shift_reg。而在for loop里面的這行代碼里面：shift_reg[i]=shift_reg[i-1]; 我們分別對這塊RAM先進行了一次讀操作：readshift_reg[i-1]，然后又進行了一次寫操作：write shirft_reg[i]，最重要的是寫操作的值是前面讀出的數據，這意味著讀寫操作之間有強相關性，所以沒有辦法Pipeline起來。因此，即使我們設置了約束讓latency=1，工具也沒有辦法實現。

那么解決辦法也很直接，我們把shirft_reg打散即可，用registers來構造shirft_reg數組：