ESL (Electronic System Level)設計理念最早可追溯至2001年，其核心思想是通過高層次語言如C/C++或圖形設計工具描述或搭建系統(tǒng)行為并對其進行仿真驗證。于是，就形成了兩個分支。分支一是從高層次語言角度出發(fā)，對應產生了如Xilinx Vitis HLS (High Level Synthesis)工具；分支二是從模塊化設計角度出發(fā)，對應產生了如Mathworks的HDL Coder、Xilinx的Vitis Model Composer等工具。這些工具在其適用的場合可有效加速設計開發(fā)的進度，縮短開發(fā)周期。

　　那么如何充分發(fā)揮工具的性能得到高質量的結果呢？首先要理解其工作原理。這里我們以Vitis HLS為例加以說明。Vitis HLS要求采用C/C++描述算法和測試平臺，其基本流程如下圖所示。

　　整個流程都是圍繞C/C++模型展開的，這往往給初學者一個誤導：只要是C/C++代碼就可以通過Vitis HLS轉換為RTL代碼。實際上，從原始C/C++代碼到最終生成高質量的RTL代碼之間存在“鴻溝”：C/C++代碼是否可綜合（轉換為RTL代碼）？C/C++代碼是否可轉換成滿足實際工程需求（速度與面積）的RTL代碼？前者解決從無到有的問題，后者解決從有到優(yōu)的問題。從語言特征的角度來看，C/C++與HDL (VHDL/Verilog)有著本質的區(qū)別。第一，C/C++是順序執(zhí)行的，而HDL是并行執(zhí)行的。因此，采用C/C++描述算法時，算法的執(zhí)行順序可通過語言的描述順序直觀地體現(xiàn)出來。HDL(Hardware Description Language)描述的是硬件電路，一旦上電，所有電路單元并行工作，HDL的并行特性正體現(xiàn)了硬件電路的這一特征。第二，C/C++是靜態(tài)的，HDL是動態(tài)的。所謂靜態(tài)是指我們在使用C/C++描述算法時，只需關注算法本身，而使用HDL描述算法時，我們要關注的是如何將算法映射為硬件電路，關注每個時鐘周期電路應實現(xiàn)的行為。電路在時鐘的作用下工作，數(shù)據(jù)在時鐘的作用下流動。第三，C/C++是沒有時序性的，而時序是HDL的一個顯著特征。無時序可以使設計者將焦點放在算法的描述上，得益于此，設計者可以采用C/C++快速完成算法建模。HDL的時序特性要求設計者盡可能采用流水線的方式使數(shù)據(jù)在各個處理單元之間流動，同時設計者還要管理好每個處理單元完成操作所需要的時鐘周期個數(shù)，保證在期望的時鐘周期個數(shù)之后獲得目標結果。時序性還要求設計者在進行電路描述時要考慮到后期的時序收斂，因此設計過程中考慮關鍵路徑的邏輯級數(shù)、扇出等因素變得尤其重要，這也導致了傳統(tǒng)RTL代碼設計流程比較耗時。

　　盡管C/C++和HDL存在巨大差異，但兩者并不是徹底地割裂開來，而是隱含著一些對應關系，這些對應關系對于我們描述HLS設計大有裨益。C/C++是順序執(zhí)行的，HDL也存在順序執(zhí)行的電路，那就是狀態(tài)機。因此，對于C/C++中的for循環(huán)，從狀態(tài)機的角度看，可分為空閑狀態(tài)->進入循環(huán)->執(zhí)行循環(huán)體->判斷循環(huán)是否結束->退出循環(huán)這樣幾個狀態(tài)。HLS會將for循環(huán)映射為相應的狀態(tài)機。這幾個狀態(tài)中，執(zhí)行循環(huán)體最為耗時，尤其是涉及到大量計算時，往往成為for循環(huán)Latency的瓶頸。用HDL描述狀態(tài)機時，我們要考慮狀態(tài)轉移條件、每個狀態(tài)持續(xù)的時鐘周期個數(shù)。就for循環(huán)而言，進入/退出for循環(huán)各需要一個時鐘周期，單次for循環(huán)所需的時鐘周期個數(shù)取決于循環(huán)體內的操作。整個循環(huán)所需的時鐘周期個數(shù)與循環(huán)次數(shù)緊密相關，這就要求我們使用for循環(huán)時盡可能保證循環(huán)邊界是固定常數(shù)。C/C++最常用的一種數(shù)據(jù)類型之一是數(shù)組，數(shù)組其實就是一段存儲數(shù)據(jù)的空間，既然可以存儲數(shù)據(jù)，那么這個空間是有記憶的。FPGA中的記憶元件包括寄存器和RAM。因此，數(shù)組最終都可以映射為這兩類原件。在HDL中描述RAM時，我們必須指定RAM的深度和寬度，從而使得工具可以在FPGA中分配固定的存儲單元。盡管C/C++支持動態(tài)可調的數(shù)組深度，但應用于HLS時，卻是不支持的。換言之，HLS要求C/C++中的數(shù)組必須為固定深度和固定寬度，這和HDL的要求是一致的。

　　除了這些對應關系，Vitis HLS還對原本的C/C++進行了改進，以更友好地匹配硬件需求。C/C++中的各種運算如加/減/乘/除/邏輯運算/關系運算等，設計者在使用這些運算時為了獲得更大的動態(tài)范圍以防止溢出或精度損失，往往采用浮點類型或較為寬泛的int類型。這些運算轉換為RTL代碼時，都會消耗相應的邏輯資源，包括查找表、觸發(fā)器、DSP等。顯然，較大的數(shù)據(jù)位寬也會消耗更多的資源。為此，Vitis HLS引入了任意精度類型包括整型和定點類型，數(shù)據(jù)位寬從1到1024，從而打破了原始C/C++以8為邊界的位寬的限制。更為重要的是，該數(shù)據(jù)類型可以完全匹配原始C/C++所支持的算術操作符。

　　有了這些知識儲備，我們就不難理解Vitis HLS的工作原理了。本質上，Vitis HLS在將C/C++轉換為RTL代碼時分為三大過程：進度安排(Scheduling)、綁定(Binding)和狀態(tài)提取。進度安排實際上解決的是什么時候做什么事，進一步而言就是每個時鐘周期需要執(zhí)行的操作。綁定解決的是完成這些事需要什么資源，進一步而言就是這些確定操作需要消耗的硬件資源。狀態(tài)提前則是從C/C++代碼中提取出狀態(tài)機，控制子函數(shù)/子操作的執(zhí)行順序。

　　從宏觀來看，對于算法較為復雜（分支條件繁多、存在反饋路徑或判斷條件復雜）的情形，采用HLS實現(xiàn)是一個很好的選擇。一個總體原則是盡可能將反饋路徑封裝在一個函數(shù)之內，確保從頂層函數(shù)看到的數(shù)據(jù)流是單向的，如下圖所示，這有利于工具使用DATAFLOW（一種pragma）提高設計的吞吐率。

　　從微觀來看，除了考慮數(shù)據(jù)位寬這一因素之外，還要考慮數(shù)組的訪問方式。數(shù)組往往映射為RAM，而一個RAM最多提供兩個輸出端口，這意味著一個時鐘周期最多讀出兩個數(shù)據(jù)。因此，對于數(shù)組的訪問，我們盡可能做到減少訪問次數(shù)提高讀取數(shù)據(jù)的復用率。我們看下面這個案例。函數(shù)opt_mem_v1實現(xiàn)的是相鄰三個數(shù)相加，這三個數(shù)來自于同一個數(shù)組。每次循環(huán)要從指定數(shù)組中讀取3個數(shù)據(jù)。映射為RAM時，一個時鐘周期內從同一個RAM中讀出3個數(shù)據(jù)是難以實現(xiàn)的。從Schedule視圖上也能看到RAM端口的局限性。為此，我們做如下改動，如函數(shù)opt_mem_v2所示，先從數(shù)組中讀出0號地址和1號地址上的數(shù)據(jù)并將其賦給指定變量，這樣每次循環(huán)只用從原始數(shù)組中讀出一個新的數(shù)據(jù)而其他兩個數(shù)據(jù)可以繼承之前的輸出結果，從而有效減少了數(shù)組的訪問次數(shù)。

　　對于for循環(huán)，盡可能合并同邊界for循環(huán)，涉及到if條件的，盡可能將if放在for循環(huán)之內。我們看一個案例，如下圖所示，在不同邊界條件下將讀取數(shù)據(jù)賦值給不同的目標數(shù)組。這4個for循環(huán)是按順序執(zhí)行的，共消耗203個時鐘周期（66+50+42+38）。從Schedule視圖也能看到4個for循環(huán)的執(zhí)行順序。

　　實際上，這4個for循環(huán)完全可以合并，如下圖所示，這樣Latency將從203直接降低到66。

　　使用HLS對C/C++的要求并不高：不需要設計者掌握C++的高級用法，比如類，但卻要求設計者具備基本的硬件知識，明白兩者的對應關系，理解HLS的工作原理，這樣才能寫出適配HLS的高效C/C++代碼，再應用合適的pragma，就可以獲得高質量的C綜合結果。

　更多信息可以來這里獲取==>>電子技術應用-AET<<