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

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

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

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

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

當(dāng)然，我們也可以對(duì)整個(gè)函數(shù)施加PIPELINE，這樣工具會(huì)將for循環(huán)自動(dòng)UNROLL，但這同樣會(huì)造成DSP48的浪費(fèi)，因?yàn)楣ぞ卟粫?huì)對(duì)頂層函數(shù)的形參數(shù)組自動(dòng)進(jìn)行ARRAY_PARTITION。于是，我們考慮手工添加ARRAY_PARTITION，同時(shí)對(duì)函數(shù)添加PIPELINE，從而使得數(shù)據(jù)通路完美匹配。

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

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

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

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

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

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

審核編輯：湯梓紅