相比于VivadoHLS，Vitis HLS更加智能化，這體現(xiàn)在Vitis HLS可以自動探測C/C++代碼中可并行執(zhí)行地部分而無需人工干預添加pragma。另一方面VitisHLS也會根據(jù)用戶添加的pragma來判斷是否需要額外配置其他pragma以使用戶pragma生效。為便于說明，我們來看一個簡單的案例。

如下圖所示代碼，函數(shù)array_mult用于計算兩個一維數(shù)組對應元素差的平方。數(shù)組長度為N，故通過N次for循環(huán)可完成此操作(這里N為8)。

如果我們不添加任何pragma，從C綜合后的報告來看，工具會自動對for循環(huán)添加PIPELINE，如下圖所示。同時，工具會將數(shù)組映射為單端口RAM(因為數(shù)組是頂層函數(shù)的形參，故只生成單端口RAM需要的端口信號)，這樣匹配了DSP48的接口需求(兩個輸入數(shù)據(jù)一個輸出數(shù)據(jù))。從C/RTLCosim的波形可以看到輸入/輸出數(shù)據(jù)流關系。

如果我們對for循環(huán)施加UNROLL，理論上分析可知工具應將for循環(huán)展開(復制8份)，這樣會消耗8個DSP48，如下圖所示。這就需要能同時有16個數(shù)據(jù)提供給這8個DSP48，但此時工具只是將數(shù)組映射為雙端口RAM。這顯然造成了數(shù)據(jù)通路的不匹配。這其實造成了DSP48的浪費。這里，因為數(shù)組是頂層函數(shù)，故工具并沒有對其施加ARRAY_PARTITION，但如果是子函數(shù)的形參，工具就會自動對數(shù)組施加ARRAY_PARTITION，以確保數(shù)據(jù)通路的匹配。

因此，我們換個思路，既然工具至多會將數(shù)組映射為雙端口RAM，那么我們就將for循環(huán)復制兩份，從而實現(xiàn)數(shù)據(jù)通路的匹配。這可通過UNROLL的選項factor設置為2。從C綜合報告來看，消耗了2個DSP48，同時工具對for循環(huán)自動設置了PIPELINE。

當然，我們也可以對整個函數(shù)施加PIPELINE，這樣工具會將for循環(huán)自動UNROLL，但這同樣會造成DSP48的浪費，因為工具不會對頂層函數(shù)的形參數(shù)組自動進行ARRAY_PARTITION。于是，我們考慮手工添加ARRAY_PARTITION，同時對函數(shù)添加PIPELINE，從而使得數(shù)據(jù)通路完美匹配。

我們對這些Solution進行對比，如下圖所示。solution1消耗資源最少，但Latency最大;solution5消耗資源最多，但Latency最小。

solution1：僅對for循環(huán)施加pipeline。

solution2：僅對for循環(huán)施加UNROLL。

solution3：僅對for循環(huán)施加UNROLL并將factor設置為2。

solution4：僅對函數(shù)施加PIPELINE。

solution5：對函數(shù)施加PIPELINE，對輸入/輸出數(shù)組施加ARRAY_PARTITION(Complete)。

審核編輯：湯梓紅