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

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

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

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

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

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

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

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

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

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

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

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