跟Xilinx SAE 學HLS系列視訊講座筆記（4）——For循環優化

目錄

• 第一講 For循環優化的性能名額
• 第二講 for循環優化-循環合并
• 第三講 for循環優化-資料流
• 第四講 嵌套for循環優化
• 第五講 for循環優化其他方法

本節主要介紹的是《跟Xilinx SAE 學HLS系列視訊講座》第15，16，17，18，19節。

跟Xilinx SAE 學HLS系列視訊講座筆記（1）

跟Xilinx SAE 學HLS系列視訊講座筆記（2）—— 編寫高效的C Test Bench

跟Xilinx SAE 學HLS系列視訊講座筆記（3）—— 接口綜合

跟Xilinx SAE 學HLS系列視訊講座筆記（4）—— For循環優化

跟Xilinx SAE 學HLS系列視訊講座筆記（5）—— 數組優化

跟Xilinx SAE 學HLS系列視訊講座筆記（6）—— 函數優化

第一講 For循環優化的性能名額

本節主要講解為：

• 與for循環相關的基本概念
• Pipelining的for循環
• for循環的展開
• for循環的循環變量的資料類型，是否對綜合後結果的資源有所影響。

  

1. 衡量名額

loop trip count :循環執行了幾次

loop interation latency :循環一次用了幾個cycle

loop interation latency(Loop II) :兩次循環直接間隔了幾個cycle

loop latency:整個for循環的latency

function latency

function initial interval（II）

2. 流水線優化

設定比較簡單

采用Pipeline前後對比我們可以發現，在不采用流水線的時候是過程化運作（有時間的先後順序進行）；當采用流水線後，當在讀資料的時候，下一個Fou循環就開始讀位址，會有并行（橢圓标記的位置）的效果。

3. For循環展開

預設情況下，C函數中的For循環是被折疊的，即每次循環均采用同一套電路，它是分時複用的；所謂的展開是複制了多個相同的電路，進而允許所有疊代并行發生。

我們也可以把For循環部分展開，如下例所示，将For循環拆解成了3部分，被複制後(0,3),(1,4)和(2,5)分别共用一套邏輯資源。

4. i的資料類型

通常情況下i的資料類型是不會對資源的配置設定産生影響。

如下例子，Vivado HLS考慮到疊代次數被限制為6次，并為每個列出的資料類型使用最少的FPGA資源。是以，每種資料類型對資源使用情況都相同。

5. 總結

• 清楚地了解Il和loop/function latency
• Pipelining是減少循環延遲的一種非常流行的方法
• 展開允許循環主體并行運作
• 部分展開可以在并行性和資源之間進行折中
• 疊代類型不影響面積結果
• 循環變量的資料類型，對最終的資源消耗量沒有影響。

第二講 for循環優化-循環合并

1. 例子引入

這個例子有兩個for循環，這兩個for循環分别執行的是加法和減法。他們是可以并行執行的，我們所期望的計算方式為圖右所示。

但實際的的處理方式，是按順序執行的，是以latency就會比較的長，這不符号我們預期的結果。

在Vivado HLS提供了一種方式，将for循環進行合并，我們也是以引入了一個新的概念叫做region（下圖綠線框對應的部分），這樣循環合并部分就是region這一部分。

合并之後

由此我們可以得出合并可以在某種程度上幫助減少延遲。

2. 循環邊界為不同的常數

如果循環界限是不同常量，則将最大常數值用作合并循環的界限。

3. 變量邊界和常數邊界

在沒有合并時候，我們會發現Trip Count為0~15，這是因為k的變量類型為

ap_uint<4>

，其資料上限位15。當我們實施循環合并時會報錯（無法合并）。這說明變量邊界和常數邊界無法合并。

4. 循環邊界均為變量

當我們實施合并循環也會産生錯誤資訊

我們可以通過修改代碼去解決。

5. 循環合并規則

情況	合并結果
固定常數	将最大常數值用作合并循環的邊界
均為變量	不能進行直接合并，可以通過更改代碼去解決（保證邊界大小相同）
一個常數一個變量	沒有辦法合并

6. 總結

第三講 for循環優化-資料流

1. 例子引入

這個例子有3個循環，分别是Task A，Task B和Task C，資料流如圖右所示，可以發現Task B依賴于Task A，Task C依賴于Task B。我們可以采取什麼措施來減少延遲？我們可以采用Pipeline，for循環的合并是不可以的。

2. Dataflow for 'For-Loop’

在沒有使用Dataflow時，三者執行順序為A—>B—>C，沒有交疊。使用Dataflow後，我們在三個循環之間加入channel（Ping-pong RAM，FIFO或Register），通道可確定不需要任務等待上一個任務完成所有操作才可以開始，此時循環之間是一個并行的關系，三者之間是有交疊的，這可以減少延遲提高資料的吞吐量。

性能展示

注：預設情況下，通道是通過ping-pong RAM實作的。通過conifg_dataflow，可以将實作方法更改為FIFO。

3. Dataflow優化限制

以下代碼樣式使Vivado HLS無法執行DATAFLOW優化

• Single-producer-consumer violations
• Bypassing tasks
• Feedback between tasks
• Conditional execution of tasks
• Loop scopes with variable bounds
• Loops with multiple exit conditions

我們如何進行優化使他可以使用

Bypassing Tasks Model

我們如何進行優化使他可以使用

4. Configuring Dataflow Memory Channels

Vivado HLS根據資料producer和consumer 的通路方式，将任務之間的通道實作為ping-pong或FIFO buffers。

• 對于标量，指針和 reference parameters以及函數傳回，Vivado HLS将通道實作為FIFO。
• 如果參數（producer和consumer ）是一個數組，則Vivado HLS将該通道實作為一個ping-pong buffers或FIFO，如下所示

1. 如果Vivado HLS确定按順序通路資料，則Vivado HLS将存儲通道實作為深度為1的FIFO通道.
2. 如果Vivado HLS無法确定資料是按順序通路的，或者無法确定資料是以任意方式通路的，則Vivado HLS将記憶體通道實作為ping-pong buffers。

5. 明确指定預設通道

使用

config_dataflow

配置

• 此配置為設計中的所有通道設定預設通道。
• 要減少通道中使用的記憶體大小，可以使用FIFO。
• 要顯式設定FIFO中元素的深度或數量，請使用

  fifo_depth

  選項。

  

6. 總結

第四講 嵌套for循環優化

1. 三種分類

2. A Simple Example of Perfect Loop

矩陣對應元素相乘，我們對内部for循環做Pipeline和對外部for循環做Pipeline的情況對比，如下。

• Pipeline最裡面for循環可為大多數應用使用更少的硬體資源（與外部for循環相比），并具有通常可接受的吞吐量。
• 對層次結構的高層進行Pipeline，會展開所有子循環，并可以建立更多要排程的操作（這可能會影響運作時間和記憶體容量），但通常在吞吐量和延遲方面提供最高性能的設計。

第五講 for循環優化其他方法

本節主要講解為：

• 有關循環并行性的問題
• for循環做流水如何使用rewind
• for循環的邊界是變量時，如何處理

1. 并行性

預設情況下，Vivado HLS對for循環做順序執行的。雖然合并這些循環可以減少等待時間，但有時循環邊界是變量和常數，是以無法合并循環。

因為這兩個for循環是獨立存在的，我們可以定義一個函數并且調用兩次，但是在預設情況下，HLS嘗試通過多次使用該功能來節省資源，而不是通過并行運作兩個副本來節省時間。是以結果與上文情況相同。

我們可以采用ALLOCATION使這兩個副本并行運作，進而減少延遲性，配置與結果如下圖所示。

2. Loop Pipeline with Rewind Option

當函數中有多個循環時候，我們做Rewind，會爆出警告，沒有辦法執行，是以我們可以看出Rewind不是所用的for循環都是适用的。

如何對for循環自動添加流水

config_compile

配置使循環可以根據疊代計數自動進行Pipeline處理。

• pipeline_loops選項設定疊代限制
• 疊代次數低于此限制的所有循環将自動Pipeline
• 預設為0：不執行自動Pipeline的循環

如果設計中有不想使用自動自動Pipeline的循環，則将帶有off選項的PIPELINE指令應用于該循環。off選項可防止自動循環流水線。

Addressing Failure to Pipeline

當任務Pipeline時，層次結構中的所有循環都會自動展開

• 這是進行Pipeline處理的要求
• 如果循環具有變量邊界，則無法展開該循環，這将防止任務被Pipeline，因為Vivado HLS無法知道循環何時完成

  

3. Variable Loop Bounds

當循環的邊界為變量的時候，Vivado HLS将不能夠确定的知道延遲為多少（報告為問号"?"），即設計性能未知。

對于這種情形我們有三種處理方式。

• 使用Tripcount指令
• 将循環邊界的資料類型聲明為

  ap_int <w>

• 在C代碼中使用assert macro

Tripcount指令

Tripcount指令對綜合結果沒有影響，僅對報告有影響，可以比較來自不同解決方案的報告。

資料類型聲明為

ap_int <w>

在C代碼中使用assert macro

對三種做對比

我們可以發現第三種方法的效果是最好的

4. 總結