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

我們做過的優化主要有：
在頭文件定義中，把數據和系數的精度都改成了整形，用18bit來表示；
在fir.c的for loop里面，修改代碼結構，只顯性的出現一處乘法描述；
把fir.c中的shift_reg，在HLS中約束只用reg來實現
約束Shift_accum_Lopp的Pipeline屬性II=1
通過這4處改進，我們成濾波器資源消耗，和Latency數據如下：

在這一章，讓我們再嘗試從另外一個角度，繼續改進這個fir濾波器。

從上述資源報告中DSP48E的消耗個數，以及Latency，我們知道現在的濾波器采用的是串行的處理方式。這和我們在數字信號處理課程中，常見的FIR濾波器結構是不太一樣的。有經驗的讀者，肯定會回憶起，我們在課本里常見的濾波器長得大概是下面這個樣子：

這是一種并行的處理結構。一個11階的濾波器，就需要消耗11個乘法器，和多個加法器。所有的這些運算都可以并行的執行，并在一個周期內完成。這樣的處理在速度上當然是最好的，雖然它意味著消耗更多的資源。那么我們如何才能綜合處上述結構的濾波器呢？

HLS提供了一條專門的約束語法，HLSUNROLL，用以約束loop循環展開，也就是并行執行。下面我們來試試這條約束，添加完成后如下所示：

那我們綜合一下，看看結果如何：

我們可以看到，把for loop展開后，總的latency確實減小了很多，從上篇文章中的18減小到了9。而且DSP消耗也從1個變成了8個。

效果還不錯！但是請稍等等，這個是最好的結果了嗎？稍微留一下，我們會發現1個問題
如果是全部展開的操作模式，那么理論上，所有的這些計算應該在1個clock cycle之內就可以完成，而現在卻消耗了9個clock cycle；
那么是什么地方的限制，導致了無法達到我們理想的目標呢？

問題出在接口的優化上。在下圖中，我們可以看到，fir函數的系數參數C被映射成了一個雙端口RAM，這意味著我每個時鐘周期僅能取2個系數進行運算，總共16個系數一共需要8個時鐘周期才能提取完畢?？磥砭褪遣磺‘數腃端口，影響了我們HLS工具的進一步優化。

明確問題后，解決辦法也很簡單。我們可以通過約束，設置把C[N]端口完全打散，讓它在rtl頂層，變成一組信號輸入，這樣就可以做到1個時鐘周期把所有的系數都提取進來進行運算。操作方式非常類似于之前的把shirft_reg打散的步驟：

經過這個優化后，我們再來看下資源和Latency，效果很不錯：

接口上也有很大的變化：

至此，這個fir濾波器的優化工作基本可以告一段落了。我們通過修改代碼，添加HLS約束等手段，成功實現了一個不論是效率，還是資源使用，都比較合理的fir濾波器。