用Verilog還是用HLS來進行FPGA設計有答案了！

經常聽人說，Verilog或VHDL與HLS相比，就好比是幾十年前的彙編語言與C語言，HDL遲早會被HLS取代的。這些話已經講了有一二十年了，還是沒有看到HLS取代HDL。本文翻譯自2019年TCAD雜誌上一篇綜述，調研和對比了近年已發表論文中採用HLS和HDL的各種使用情況，值得一看。

摘要：為了提高設計數字硬件組件的效率，高層綜合（HLS）被視為提高設計抽象水平的下一步。但是，HLS工具的結果質量（QoR）往往落後於手動寄存器傳輸級別（RTL）流程的質量。在本文中，我們調查了自2010年以來發表的有關HLS和RTL設計流程之間的QoR和生產率差異的科學文獻。我們的調查總共涵蓋46篇論文和118篇相關申請。我們的結果表明，平均而言，RTL流程的QoR仍然優於最新的HLS工具。但是，使用HLS工具的平均開發時間僅為RTL流程的三分之一，並且設計人員使用HLS可以獲得的生產率是其四倍以上。根據我們的發現，我們還提供了一個模型案例研究，以總結HLS和RTL之間的比較研究中的最佳實踐。我們的案例研究的結果也與調查結果一致，因為使用HLS工具可以使生產率提高六倍。此外，為了幫助彌合QoR差距，我們提供了一份針對改善HLS的文獻調查。我們的結果使我們得出結論，HLS當前是用於快速原型設計和較短上市時間的可行選擇。

引言

數十年來，寄存器傳輸級別（RTL）一直是描述超大規模集成（VLSI）系統及其組成知識產權塊的主要方法。儘管RTL工具只是逐步發展的，但VLSI系統的複雜性卻呈指數級增長，這使設計和驗證過程成為生產力的瓶頸[1]。

高級綜合（HLS）有望通過各種方式來緩解此問題[2] – [3] [4] [5]。在HLS中，在行為級別上描述了該應用程序，省略了實現細節，例如時序以及接口和存儲元素的性質。這些詳細信息是使用HLS工具確定的，該工具將行為描述作為輸入。設計人員可以在工具中選擇目標技術，並將接口和內存變量映射到指定的技術相關元素。然後，HLS工具會根據目標技術和微體系結構選擇生成RTL描述。

HLS的承諾很多。

1. 通過提高抽象級別，可以減少最初的設計工作量。設計人員可以集中精力描述系統的行為，而不必花費時間來實現微體系結構的細節。在更高的抽象級別上，也不太可能在代碼中引入錯誤。
2. 驗證被加速。通常可以使用軟件驗證工具來驗證設計的行為，該軟件驗證工具比RTL仿真工具更容易使用。此外，HLS工具的RTL輸出可以使用原始的行為測試臺進行驗證，因為該工具可以檢查兩個模型的結果是否相同。
3. 設計空間探索（DSE）更快。可以通過在HLS工具中進行選擇來探索微體系結構，這些選擇幾乎不需要修改代碼。因此，可以在數小時內探索幾種轉換，例如流水線化和各種循環展開因子。這是對RTL方法論的巨大改進，在RTL方法論上，此類更改將需要對源代碼進行重大修改。
4. 定位新平臺非常簡單。如果目標平臺發生變化，則HLS工具能夠相應地修改RTL輸出。例如，如果新平臺具有不同的時鐘頻率，則HLS工具將根據新頻率重新安排操作。
5. 軟件工程師可以訪問HLS。RTL設計需要了解VHDL和Verilog等語言，而HLS工具通常使用熟悉的語言，如C / C ++。HLS工具可以處理大多數特定於硬件的實現細節，因此大大降低了軟件工程師處理硬件項目的門檻。也就是說，為了獲得最佳結果，在使用HLS時，硬件專業知識仍然有用。

這些好處加在一起，減少了設計和驗證時間，降低了開發成本，並降低了進行硬件項目的門檻。因此，縮短了產品上市時間，並且在異構系統上使用硬件加速已成為更具吸引力的選擇。

現場可編程門陣列（FPGA）的興起也是HLS的推動因素。FPGA是HLS設計的理想平臺，因為它們可以快速進行原型設計，具有快速的設計週期並且具有固有的可重新編程性。現代的HLS工具通常包含用於設計目標的廣泛的FPGA技術庫。

HLS的歷史可以追溯到1970年代和1980年代，但是直到世紀之交，它才成為該行業的可行選擇[2]。緩慢採用的原因之一是結果質量（QoR），例如資源使用和性能，最初與RTL方法相比較差。使用最新一代的HLS工具可以改善QoR，但是個別研究報告的結果仍然不同，目前尚不清楚QoR差距是否已經消除。

本文的目的是通過文獻綜述來回答這個問題。我們檢查了46篇最新論文，比較了針對相同應用的HLS和RTL方法的QoR和開發工作。本文有四個主要貢獻。

1. 對科學文章中報道的HLS和RTL流程的QoR和設計工作的比較分析。
2. 案例研究介紹了將HLS和RTL方法與使用這兩種流程來實現HEVC / H.265視頻編碼器的一部分的測試組進行比較的最佳實踐。
3. 文獻調查表明瞭改善HLS的研究方向和方法。
4. 關於HLS的最新技術的結論。

據我們所知，這是第一項全面的定量研究，它使用多種來源來比較HLS和RTL流程的QoR和設計工作。相反，先前的工作著重於將不同的HLS工具彼此進行比較[6]，[7]。其他論文提供了有關如何彌合RTL的QoR差距或以其他方式改進HLS工具的見解[5]，[8]。但是，缺少對HLS當前狀態的全面定量分析，對此進行了修改。

本文其餘部分的結構如下。第二部分介紹了我們選擇定量分析論文的標準。第三節包含對已審閱論文的薈萃分析，總結了其中所報告的信息類型。在第四節中，我們顯示並分析了文獻研究的結果，第五節介紹了我們的測試組研究及其結果。第六節回顧了提出對HLS進行改進的論文，最後，第七節總結了本文，並對結果進行了一些討論。

相關論文

在本文中，我們研究了2010年或以後發表的文章，以全面瞭解HLS的最新作品。我們總共找到了超過一千篇候選論文，並選擇了需要進一步研究的文章，其摘要指出：1）使用HLS實現了一個或多個應用程序，以及2）將獲得的結果與同等的自制或參考RTL應用程序進行了比較。

我們還要求符合條件的論文必須列出下列一項或多項指標，用於HLS和RTL版本的申請：

• 應用特定指標的性能。
• 執行時間和/或延遲。
• 目標平臺上可達到的最大時鐘頻率。
• 專用集成電路（ASIC）上的區域。
• FPGA上的資源使用情況。
• 能量消耗。
• 開發時間。
• 輸入源代碼（LoC）的行。

最終，我們一共發現了46篇合格論文，其中39篇來自IEEE Xplore，兩篇來自Springer Link，一篇來自ACM Digital Library，兩篇來自arXiv.org，一篇來自EBSCOhost，另一篇來自Science Direct。附錄表IX中提供了所有已審閱論文的基本信息。從表中可以看出，應用範圍非常廣泛。這使得按應用類型分析QoR結果不切實際，否則將對HLS的優缺點提供有趣的見解。這樣的定性分析也將受益於很少獲得的實現的源代碼。

表一顯示了每年發表的合格論文數量。由於每年發表的論文數量較少，因此用我們的數據來檢查這些年內HLS的QoR可能的趨勢是不可行的。對於這類研究來說，較長的年份範圍也是比較好的。

分析

表II彙總了所關注論文中關注指標及其發生的頻率。一般而言，所審查的作品在有關實驗設置和結果的報告細節方面差異很大。該表僅統計那些以絕對值或百分比精確報告結果的論文。我們的定量分析排除了諸如“執行時間少於100毫秒”之類的不精確值。

表II 指標及其在審閱論文中的出現頻率

22篇文章報告了多個應用程序或實驗設置的結果。在許多作品中，實現了多個不同的應用程序，這些應用程序經常彼此關聯（例如[9] – [10] [11]）。一些作者比較了不同的HLS工具[12] – [13] [14]，而其他作者比較了各種微體系結構優化，例如循環展開和流水線[15]，[16]或不同的FPGA芯片[17]和[18]。。因此，數據集比僅合格論文所建議的數量要大。為簡便起見，我們將分別稱為這些結果申請表，無論它們是基於實際的不同應用，HLS工具，FPGA芯片還是其他版本。表II的第三列顯示了報告給定指標的應用程序總數。

比較HLS和RTL方法時，開發時間非常受關注。但是，只有三分之一的論文報告了開發時間，這在忽略它的文章中被視為一個缺陷。在各種QoR指標中，報告的FPGA資源使用率要比性能值高。只有四篇論文針對ASIC實現（而非FPGA），因此沒有足夠的數據來比較ASIC面積結果。功耗也是如此。

幾乎所有論文都報告了使用的HLS工具。其餘作品沒有理由不透露信息，但許可協議可能是原因。但是，即使那些文章也提到了HLS輸入語言。

表III彙總了所使用的HLS工具。第二列告訴每個工具出現的次數，第三列告訴他們輸入語言。該表表明，至少在學術界，Vivado HLS（以前稱為自動駕駛儀）是最受歡迎的HLS工具。所有其他工具僅獲得分散的使用。Vivado之所以受歡迎，可能是因為Xilinx是領先的FPGA供應商，其FPGA設計套件包括Vivado HLS。大量使用過的HLS工具還說明了該領域的相對不成熟。

表III 按論文分列的HLS工具使用情況

在46項合格作品中，有39項使用自制的RTL實現方案與HLS進行了比較，還有7項引用了其他研究組提出的RTL結果。還有其他一些可以勝任本論文的工作，但是他們引用了具有不兼容的RTL實現的論文，因此被排除在外。例如，用於RTL的FPGA芯片來自不同的家族，這妨礙了公平地比較資源使用情況。

研究結果比較

A.關於QoR指標

FPGA的基本構建塊是可配置邏輯塊（CLB）或邏輯陣列塊（LAB），具體取決於FPGA供應商和器件。CLB / LAB由幾個邏輯單元組成，這些邏輯單元可以稱為邏輯單元（LC），邏輯元件（LE）或自適應邏輯模塊。這些邏輯單元由查找表和觸發器組成。綜述的論文通常在為FPGA合成應用程序時報告這些圖之一。就本文而言，與報告哪個數字無關，因為我們對HLS和RTL之間的資源使用比率感興趣。因此，我們將所有這些資源指標歸為同一術語，稱為基本FPGA資源。

FPGA還包含其他資源，例如DSP塊和片上塊RAM（BRAM）存儲器，如果沒有FPGA供應商的足夠數據，則無法將其轉換為CLB等效項。這將需要知道確切的FPGA芯片類型，但是隻有大約60％的審閱論文對此進行了報告，而其他論文僅陳述了所使用的FPGA系列。因此，我們沒有一種通用的方法將所有資源指標組合為一個資源使用價值，可以在各個應用程序之間進行比較。因此，我們放棄了這種方法，而是選擇CLB或其組成部分作為資源使用情況比較的基礎。

審閱的論文還根據實現的應用程序使用了各種不同的性能指標。這些可以分為四類：1）性能；2）執行時間；3）延遲；4）最大頻率。在這種情況下，可以根據應用以幾種方式解釋性能。例如，對於視頻編碼器，這表示每秒的幀數，對於加密模塊，則表示每秒的加密位。對於具有清晰開始和結束的應用程序，通常會報告執行時間，有些論文會報告延遲，即處理樣本的時鐘週期數。最常報告的性能指標是可以在目標FPGA上調度應用程序的最大頻率。

我們希望包括儘可能多的性能指標，以便在本文中全部使用。對於報告多個指標的論文，我們將性能優先於執行時間，優先於延遲而不是延遲，將延遲優先於最大頻率。因此，我們在每個應用程序中僅使用這些值之一，而不是嘗試創建任意的聚合性能指標。在以下各節的圖中，我們將所選值稱為Performance。我們還在數字的計算中反轉了執行時間和等待時間值，因此值越大越好。在以下各節中檢查各種數據雲圖形的方法不是將各個數據點相互比較，而是集中在重心和數據分散性上。

B 數值分析

表IV收集了我們發現的數值彙總數據。ñ 表示報告了相應數據的申請數量。第三列報告HLS和RTL結果之間的比率平均值。對於除DSP模塊和BRAM以外的所有值，我們使用幾何平均值而不是算術平均值，因為由於應用範圍廣泛，每個類別中的值可能相差一個數量級。對於DSP模塊和BRAM，由於數據集中的零，因此無法計算幾何平均值，因此使用了算術平均值。粗體均值支持HLS，而非粗體均值支持RTL。第四列顯示幾何標準偏差（GSD）。請注意，它是一個乘法值：下限是通過除以GSD獲得的，上限是通過乘以GSD獲得的。

表IV 論文數值數據摘要

不出所料，HLS在開發時間和源代碼行方面均優於RTL。平均開發時間僅為相應RTL應用程序的三分之一。我們還檢查了HLS與RTL的開發時間比例與絕對開發時間的關係看看項目規模是否對比率有影響，但沒有相關性。因此，對於大型和小型應用程序來說，減少的開發時間似乎是相同的。另一方面，分別與代碼大小的比較表明，對於較大的應用程序（1000 LoC或更多），HLS代碼似乎比RTL代碼更緊湊。實際上，在所有情況下，HLS LoC比RTL LoC多，代碼大小小於250 LoC。使用較小的代碼大小，非行為代碼將在總代碼中佔相對較大的部分，這似乎有利於RTL。

在性能和執行時間上，HLS設計的平均水平明顯較差，但在延遲和最大頻率方面，差異不那麼明顯。HLS方法還會浪費基本資源：平均而言，HLS使用的基本FPGA資源比RTL多41％。使用BRAM和DSP模塊，結果是矛盾的。基於報告已使用的BRAM塊數量的論文，HLS似乎更有效地使用它們，但是對於報告以千位為單位的BRAM使用情況的論文，RTL勝出。在DSP塊使用中，HLS和RTL看起來很相似。

我們還研究了HLS輸入語言如何影響QoR。在[19]，HLS工具根據其描述輸入的樣式分為五類：諸如框架的硬件描述語言（HDL），基於C的框架，基於高級語言（HLL）的框架（這些是高度抽象的，通常是對象面向語言），基於模型的框架（使用可執行規範，例如NI LabView和MATLAB HDL Coder）以及基於CUDA / OpenCL的框架。在本文中，我們發現有5個使用HDL的應用程序，例如77個基於C的應用程序，10個基於HLL的應用程序，六個基於模型的應用程序和11個基於CUDA / OpenCL的框架。由於基於C的框架以外的框架僅接受分散的用法，因此不明智地將所有類別相互比較。相反，我們比較了基於C的框架和所有其他框架的QoR。結果顯示在表V中，其中ñ 表示可比較結果的數量。似乎基於C的框架所產生的設計性能要比其他框架差，但可以節省基本資源的使用。進一步研究數據，我們注意到基於CUDA / OpenCL的框架特別消耗資源（3.56 × ）併產生了最差的效果（0.56 × ）。

表V 按框架類型比較QoR

C.資源使用情況和性能之間的比較

為了更好地說明QoR差異，圖1顯示了相對HLS / RTL性能相對於每個應用程序的相對HLS / RTL基本資源使用情況。圖中的每個“ X”代表一個應用程序。較寬的水平線和垂直線表示收支平衡線，其中HLS和RTL的性能和基本資源使用率分別相同。大多數標記都聚集在收支平衡線的交點附近，這表明在大多數情況下，HLS和RTL之間的性能和基本資源使用方面的差異相對較小。儘管如此，相對於相反的方向，在圖的右邊和底部有更多的標記，這表明RTL在這兩個方面都傾向於不及HLS。

圖1. 不同應用程序的性能和基本資源使用率之間的HLS與RTL之比的散佈圖。

圖2顯示了另一種查看相同數據的方法，該圖顯示了HLS應用程序（“ +”）和RTL應用程序（“X ”）。較大的，部分重疊的符號對應兩個度量均基於幾何平均值顯示了重心。數據點雲在很大程度上重疊，並且重心彼此靠近。因此，平均而言，HLS和RTL QoR之間沒有根本差異，但是RTL的要好一些。

圖2-每個應用程序的HLS（橙色$ x $）和RTL（藍色+）性能以及基本資源使用情況。請注意，該性能沒有列出的單位，因為它因應用程序而異。

我們還想了解相對HLS / RTL性能與基本資源使用的絕對數量之間是否存在任何關聯。也就是說，HLS和RTL設計之間的相對性能是否根據消耗的FPGA資源而變化。我們的假設是，對於大型應用程序，HLS工具優化數據路徑和控制邏輯的能力可能會受到更大的限制。結果繪製在圖3中，該圖表明沒有明確的相關性，並且對於該數據集，皮爾遜相關係數的確僅為0.10。因此，設計的大小似乎並不影響HLS工具優化性能的能力。

圖3-HLS / RTL性能與HLS基本資源使用情況。

D.基於設計努力的比較

圖4顯示了報告了開發時間的應用程序的HLS / RTL開發時間比率。除了三種情況外，其他所有比率均小於1，而在72％的情況下，比率小於0.5。這三個應用程序的HLS開發時間比RTL的開發時間長，它們來自相同的工作[13]。作者指出，開發時間的差異是由於學習使用HLS工具所花費的時間以及修改參考C ++源代碼以達到所需吞吐量的需要。

圖4-不同應用程序的HLS / RTL開發時間比率。

同樣，圖5描繪了HLS和RTL設計之間的LoC比。在這裡，HLS的主導地位不那麼突出，但仍然很重要。在75％的情況下，HLS LoC小於RTL LoC。

圖5-不同應用的HLS / RTL LoC比。

我們還研究了LoC中的應用程序大小與HLS / RTL性能之間的可能相關性。圖6（a）示出了數據。從計算中除去右上角的三個異常值時，Pearson相關係數僅為0.04。因此，似乎代碼的大小並不表示相對HLS / RTL性能。圖6（b）顯示了相對HLS / RTL基本資源使用情況的相同數據。相關性是-0.08，因此代碼大小也不與基本資源使用率相關。兩者合計，無花果。圖3和6表示應用程序的複雜性不會影響相對於HTL的RTL性能或基本資源使用率。但是，如圖6可以看出，就LoC而言，論文中提出的大多數應用程序都相當小。由於缺少數據，因此省略了使用較大的應用程序研究各自的行為。

圖6.-HLS / RTL（a）性能比（b）基本資源使用率與HLS LoC的關係。

觀察HLS相對於RTL有用性的一種方法是檢查每個設計小時獲得的性能，如在[11]中討論的。圖7通過將HLS / RTL性能除以開發時間比率顯示了報告了性能和開發時間的所有應用程序的相對生產率。值大於1表示HLS方法在每個設計小時內提供的性能要比RTL高。平均值是4.4。在情況1到4中，RTL方法顯然是成功的。在情況5和6中，方法學大致相同，而在其他情況下，HLS是更好的方法。對於應用程序1，該條几乎是不可見的，因為該比率為0.05。此應用程序是稀疏算法矩陣乘法[11]具有動態循環邊界，不適用於HLS工具為加速計算而執行的自動優化。儘管如此，該圖表明，平均而言，使用HLS工具，設計師在每個設計小時內可獲得更高的性能。

圖7-不同應用的HLS到RTL的相對生產率。

測試研究

這項調查表明，許多先前的工作報告的HLS與RTL比較結果均不夠充分，這也使我們的數據收集變得複雜。因此，我們組織了一個案例研究，以展示在建立適當的測試以進行比較和報告結果方面的最佳實踐。案例研究的第二個目的是檢查HLS和RTL流量從用戶的角度來看有何不同，以及流量的相對生產率是多少。以前的大多數研究只集中在QoR差異上。

案例研究是為實現2D離散餘弦變換（DCT）算法[20]8 × 8 高效視頻編碼（HEVC）[21]編碼器中使用的剩餘塊。選擇DCT是因為它眾所周知並且具有適當的複雜性。

A.測試組

該測試小組由六名具有數字設計和編程基礎知識的參與者組成。如表VI所示，他們以前已經編寫了1k到100k行的C或C ++。平均而言，他們在工作或業餘項目中大約有15個月的編程經驗。參加者在硬件設計方面的經驗要少得多，他們平均只有1000行VHDL或Verilog代碼，並且在此類項目中的經驗為三個月。在進行這項研究之前，只有一名參與者完成了有關HLS的小教程，從而使該實驗成為了其餘部分中HLS的首次介紹。

表VI 測試小組的背景經驗

我們選擇了硬件經驗有限但軟件經驗適中的參與者，因為HLS承諾會隱藏特定於硬件的實施細節。因此，習慣於在軟件項目中編寫行為描述的程序員是HLS的理想讀者。確實，HLS的試金石測試是，在設計相對簡單的硬件模塊時，此類用戶可以毫不費力地產生可接受的結果。

為了獲得足夠的HLS背景知識，參與者自學了HLS基礎知識，並進行了五個小練習，以實現FPGA音頻編解碼器的各個部分。以前，他們使用VHDL RTL進行了相同的練習。

B.測試用例

在HEVC編碼器中，DCT用於轉換 8 × 8 空間域殘差塊成 8 × 8 變換域係數（tcoeff）矩陣。眾所周知的行列算法[20]在兩個連續的階段中執行具有可分離的1-D轉換的這些2-D轉換。首先將變換應用於殘差塊的每一行以生成中間矩陣，然後將其應用於中間矩陣的每一列以生成最終的變換系數矩陣。

參與者被分配為實現此2-D DCT硬件單元 8 × 8 帶有RTL（VHDL或Verilog）和HLS（帶有Mentor Graphics的Catapult-C版本8.2 m UV的C / C ++）的剩餘塊。Catapult-C支持從編寫原始源代碼到生成和驗證RTL代碼的整個設計流程。在本文中，沒有進行物理的FPGA實現，但僅使用綜合結果來獲得QoR數據。由於我們對HLS與RTL的相對結果感興趣，因此省略了執行佈局和路線（P＆R），並且P＆R不會顯著影響該比率。

提供的DCT參考包括HEVC規範及其在HEVC參考編碼器中的實現[22]。與會者還獲得了現成的SystemC測試平臺以及對接口的要求，以使測試平臺能夠正常工作。接口要求包括輸入和輸出數據總線的寬度以及相關的控制信號。RTL和HLS版本使用相同的測試平臺。它為第一遍生成隨機殘差值，併為第二遍執行必要的轉置。成功實施的條件是要通過測試平臺驗證。

還指示參與者將工作時間分配到五個類別：1）設計；2）實施；3）搜索信息；4）模擬；5）調試。他們被允許選擇是先實施HLS還是RTL版本，或者同時實施兩者。

C.結果

表VII顯示了各個測試人員執行RTL和HLS的面積和速度數字。HLS / RTL比率顯示HLS和RTL結果之間的比率。粗體字表示HLS流量何時達到更好的結果。使用參與者報告的輸出係數，等待時間，吞吐量和頻率，將速度計算為每秒百萬個變換系數。

表VII RTL和HLS設計的面積和性能圖

有四名測試人員開始了RTL實施工作。所有參與者都使用VHDL而不是Verilog編寫了RTL代碼。即使使用RTL實現了最小的面積和最高的頻率，總體趨勢是，參與者可以使用HLS工具獲得略小的面積和略高的時鐘頻率。此外，HLS設計已經結束2.5 × 速度與RTL設計一樣快，這也影響了速度與面積之比。例如，第4個人在使用HLS的所有設計中都獲得了最佳的速度與面積之比。另一方面，第3個人是唯一使用RTL獲得更快的速度與面積比的人。所有測試人員都使用多級結構來計算RTL代碼中的DCT，但是他們都沒有實現更復雜的狀態機以對連續輸入使用級流水線。在RTL情況下，缺少流水線會降低吞吐量。相比之下，與RTL相比，所有人都可以在HLS中使用循環展開和流水線操作來獲得更好的吞吐量值。

表VIII列出了HLS和RTL方法的生產率值。使用HLS工具，所有參與者的生產力顯然都更好，並且HLS的平均生產力高達RTL的6.0倍。因此，它甚至高於調查結果。我們可以推測，如果人們在其RTL實現中實現了階段流水線工作，生產力將如何改變。生產力水平不太可能轉移到支持HTL之上的RTL，因為時間使用量會隨著吞吐量的增加而增加。

表VIII HLS和RTL生產率

表IX 論文摘要

圖8顯示了五類參與者的時間使用情況。平均而言，與HLS一起工作的人在所有類別中花費的時間更少。RTL流的最大，平均和最小時間使用總計分別為37.7、15.1和3.7 h，而HLS流的相同值為25.0、10.1和1.6 h。

圖8 使用RTL和HLS的不同類別的最大，最小和平均時間使用情況。

結論是，使用HLS的所有參與者的生產率都高於使用RTL的生產率。儘管小組規模很小，並且人員的硬件背景非常相似，但這項研究表明，採用HLS比RTL更容易，並且對於擁有大多數軟件設計經驗的人員來說，更快地收到更好的結果。該結果強調了以下事實：HLS對於想要實施例如硬件加速器的軟件工程師是有用的工具。

應該注意的是，我們的結果不同於典型的調查研究，後者的RTL的QoR優於HLS的QoR。對此的可能解釋是，在接受調查的作品中，設計師比我們的測試人員擁有更多的硬件專業知識。另一方面，我們的案例研究與有關生產率的調查文獻一致，這有利於HLS。

D.測試人員的反饋

完成測試任務後，向參與者詢問HLS和RTL設計流程的優缺點，最後他們必須從中選擇自己喜歡的。答案在HLS和RTL流之間平均分配（3–3）。

與HLS相比，偏愛RTL的人們希望為HLS工具提供更多的開源支持，因為流程高度依賴於工具。這將允許更多的業餘愛好者使用HLS工具。一些測試人員還希望在HLS工具中對週期精度方面的結果RTL進行更多控制。對於他們來說，RTL更容易進行微調，並且可以使他們更好地瞭解當前的問題。

與HTL相比，HLS的支持者更喜歡HLS的易用性，HLS工具的職責是保留不必要的細節，如自動I / O握手和流水線支持。這使參與者可以集中精力定義行為描述。他們還認為RTL更加耗時，需要更多的計劃，並且很難進行重新設計。

測試人員的總體結論是，在嵌入式編程中，HLS和RTL與C和彙編語言相比。他們認為，設計人員寧願使用HLS（可用的最高抽象級別），而較低級別的RTL僅應在週期關鍵型應用程序中使用，或者應能夠顯著提高性能。

E.最佳做法

我們使用文獻調查和本案例研究來總結以下最佳實踐，以對RTL和HLS工作流程進行比較研究。

1. 應該使用一組人來實施相同的設計，以減少設計師體驗這兩種流程的影響。
2. 除非許可協議禁止，否則應報告使用的HLS工具和語言。這些選擇已顯示出會影響QoR [12] – [13] [14]。
3. 當進行專注於QoR差異的研究時，在RTL和HLS設計中應使用相同的微體系結構。但是，如果重點是生產力或HLS的可用性，則可以取消此限制。
4. 對於FPGA實施，應報告確切的FPGA芯片模型和版本以允許複製結果。
5. 應報告每個設計師的時間使用情況。此外，應該報告每個工作階段所花費的時間，以便更深入地瞭解使用HLS和RTL版本最耗時的部分。
6. 應該報告輸入代碼的行，以顯示應用程序的大小和複雜性。
7. 除了基本的QoR結果外，還應報告每個設計時間的性能，以顯示HLS和RTL流程之間的生產率差異。

彌補質量差距

我們的調查表明，對於任何給定的應用程序，HLS和RTL方法之間通常仍然存在QoR差距，通常更傾向於RTL。現有大量文獻已經認識到這一差距並提出了縮小差距的方法。在本節中，我們將對這些文獻進行調查，以向HLS研究人員和開發人員重點介紹。此外，我們將對對現有HLS流程進行新穎改進的論文進行審查。

A.工具開發人員的研究方向

Sun 等 [8]為HLS工具開發人員集中精力提供了一些建議。他們指出，資源共享和調度是當前HLS工具仍在努力的HLS技術的兩個主要功能。例如，他們演示了當僅需要13個具有最佳共享功能的硬件時，HLS工具會實例化31種特定類型的硬件操作員。他們還注意到，HLS工具混淆了源代碼和生成的硬件之間的關係，從而使識別代碼的次優部分變得困難。此外，作者呼籲業界就HLS的基於C的標準輸入語言達成一致。這將為工具用戶和工具本身提供一種明確的方式來解釋源代碼。

Rupnow 等 [57]在HLS的可用性和QoR方面都有公認的發展空間。他們的研究使用的是AutoPilot（現為Vivado HLS），但建議是可推廣的。作者建議對循環流水線和展開進行自動權衡分析，以使DSE更快。對於複雜的循環結構，可能的優化組合數量可能會非常多。此外，作者呼籲支持BRAM端口複製指令，為數據流轉換提供更強大的功能，並支持2-D訪問模式的流計算。為了改善QoR，他們建議這些工具應該檢測單獨的循環和函數之間的內存級別相關性，並自動對內存訪問進行重新排序，以允許分區，流傳輸和更好的流水線操作。這些工具還應該自動創建緩衝區，以提高內存訪問的重用性。

在[5]中也認識到了優化存儲器訪問在高質量設計中的重要性。作者指出，HLS工具通常不支持內存層次結構，也不抽象外部內存訪問。因此，要求設計人員注意總線接口和內存控制器的細節，這與行為設計範式的思想不太吻合。HLS工具應向設計人員隱藏外部存儲器傳輸，以解決此問題。本文還指出了從順序C / C ++規範中獲得任務級並行性的困難，為此作者建議開發適當的設備中性編程模型。

在[32]中，提出了在HLS工具中缺乏對動態數據結構的支持。作者採用以數據流為中心的方式並通過使用動態內存分配的遞歸樹遍歷來實現相同的算法，並觀察到使用後一種方法會明顯降低性能。通過應用幾次手動代碼轉換，作者可以提高性能，並得出結論，HLS工具應使用動態數據結構自動執行類似的優化。

B. HLS流程的改進

由於研究文章的作者通常無法訪問商業HLS工具的源代碼，因此大多數對HLS結果進行了改進的論文都是通過在設計流程中引入新的優化步驟來實現的。本節將回顧一些屬於此類的有希望的結果。

Josipovic 等[58]提出了使用並行模式模板來根據目標設備的屬性來擴展模塊實現，這超出了HLS工具的能力。作者出現了2.8 × 加快了標準HLS工具流程的速度。在[59]中也使用了基於模板的方法，其中使用針對硬件優化的通用計算模式的可組合和可參數化模板來提高性能。為了方便用戶，這些模板可以包含在HLS工具中。

在[60]中，討論了大規模並行算法中的內存訪問瓶頸問題。作者提出了一種算法，該算法可以調度在不同管線階段訪問的內存，從而減少了同時訪問的壓力。他們的方法平均將流水線性能提高了43％，並將存儲庫使用量減少了55％。[61]中討論了另一種減少內存訪問開銷的方法。本文提出了一種新穎的算法，可以在某些區域約束下選擇性地將陣列定標為片上寄存器。結果表明性能有了顯著提高。

啟用更高效的HLS的一種方法是通過識別自順序基本操作合併的自定義操作。這降低了合成算法的數據流圖的複雜性，從而減少了合成時間並提高了QoR。在[62]中已經研究了這種方法，在面積消耗，性能和代碼大小方面實現了顯著的改進。因此，HLS工具應包括自定義操作標識作為預處理步驟。

資源分配和操作綁定是HLS中的兩個基本步驟。因此，它們的有效實施對於實現良好的QoR至關重要。在[63]中，已經研究了寄存器分配的影響。本文表明，在大多數情況下，一種簡單的資源分配策略，即每個變量一個寄存器而沒有寄存器共享，可以帶來最佳的QoR結果。

HLS工具使用軟件編譯器來創建輸入程序的中間表示（IR）。然後在HLS優化步驟中使用IR。IR和編譯器選項影響QoR也就不足為奇了。黃等。 [64]研究了不同編譯器選項對QoR的影響，並開發了一種方法，僅自動選擇可改善QoR的選項，與通常的-O3優化水平相比，平均性能提高了16％。

在[65]中，觀察到可以通過合併不同的行為描述而不是分別為每個行為描述執行HLS來節省大量面積。這是因為當HLS工具可以在描述之間共享功能單元時，可以更好地共享FPGA上的功能單元。本文提出了一種在給定的等待時間約束內搜索最佳合併的算法。

C.設計空間探索

HLS工具包含各種指令，可以指導硬件綜合以生成更有效的設計。這些指令包括流水線化和循環展開以及數組分區等。由於大多數算法都包含許多循環和數據數組，因此找到一組Pareto最佳指令設置可能是一項艱鉅的任務，但這對獲得良好的QoR至關重要。因此，應該自動探索最佳設置的設計空間，但是當前領先的HLS工具無法為DSE用戶提供幫助。另一方面，有一些學術論文研究了HLS中的DSE自動化。

一種簡單的自動迭代DSE方法在[66]中提出。與非引導式HLS流量相比，該方法著重於減小面積，可將QoR提升多達50％。[67]中展示了一種基於自適應加窗方法的更復雜的DSE算法。該算法顯示出可以在運行時間和找到最佳QoR之間取得良好的折衷。專門針對具有嵌套循環的應用程序的類似方法已展示了235 × 與詳盡的DSE相比，速度更快，同時獲得了相似的結果[68]。

在[69]中，基於順序模型的優化已應用於DSE問題。本文表明，該方法可以在合理的時間內從成千上萬個可能的設計空間中找到全局最優點。在[70]中，在HLS之前添加了輕量級的預處理步驟以執行目標算法的動態相關性分析。當將這些機會作為HLS工具的約束條件時，該方法可以公開資源共享機會，從而產生更好的QoR。

在[71]中已經討論了找到最佳環路展開因子的特定但重要的問題。作者已經開發出一種算法，可以在給定的區域約束內找到最佳展開因子，並表明與其他可能的解決方案相比，該算法可以提供最佳性能。

D.驗證

驗證仍然是任何設計項目中耗時的部分。因此，HLS工具在所有階段都支持驗證流程至關重要。儘管HLS流程允許對單個模塊進行有效的行為驗證，但仍必須對生成的RTL進行非行為方面的驗證，例如接口綜合結果和成功的組件集成。HLS之後傳統的RTL驗證比較困難，因為與輸入源代碼[4]，[5]，[8]沒有直接關係。然而，在許多情況下，使用HLS可以將驗證時間減少一半[72]。

HLS的驗證方面在最近的一篇論文中進行了廣泛的討論[72]。作者指出，邏輯冗餘會降低測試覆蓋率，這是HLS的主要問題。邏輯冗餘可能出現在源規範中，但也可能在RTL生成中由HLS工具引入。因此，HLS工具的開發人員應努力消除產生邏輯冗餘的趨勢。除此之外，在驗證過程中可以使用正式的工具來識別冗餘。本文還提倡使用源掉毛作為改善HLS的一種方法。它不僅可以用於檢查錯誤源，還可以通過證明FIFO大小等屬性來幫助優化設計。

叢等。 [5]提出了三個值得注意的項目，以使大多數調試都可以在行為輸入語言級別上進行，以進行片上驗證：1）以較小的開銷添加調試邏輯的能力；2）觀察諸如FIFO之類的關鍵緩衝區的能力；3）使用源代碼中的斷點觀察硬件塊內部狀態的能力。由於計算機生成的RTL代碼，執行HLS後無法在RTL級別上實現這些重要的調試功能。

除了驗證之外，工程變更單（ECO）還在HLS方面帶來了困難[4]。發出ECO時，僅需要一些小的增量更改，這些更改通常不會被高級行為描述捕獲。另一方面，已經注意到，由於可以廣泛驗證行為源代碼，並且HLS工具確保所生成的RTL是正確的，因此ECO在HLS流中並不常見[66]。

結論

在本文中，我們檢查了46篇最近的文章，這些文章比較了HLS和RTL設計流程之間的QoR和設計工作。由於HLS有望比RTL帶來更高的生產率，因此我們的目的是瞭解現代HLS工具是否也能夠產生可與手動調整的RTL設計競爭的結果。

我們的調查表明，即使是最新一代的HLS工具，也無法提供與手動RTL一樣好的性能和資源使用。但是，結果差異很大，並且在大約40％的評估案例中，HLS被證明等於或優於RTL方法。我們自己的案例研究表明，硬件經驗有限的設計人員可以使用HLS獲得更好的結果，並且性能提高2.5倍，FPGA資源使用率略低。我們還檢查了設計的大小是否影響了HLS和RTL之間的相對QoR，但沒有發現相關性。因此，HLS似乎適合於大小設計。

在設計方面，調查顯示HLS顯然是預期的領先者。平均而言，HLS設計時間僅為相應RTL設計時間的三分之一。另外，HLS輸入代碼的大小几乎減半，平均為RTL代碼大小的52％。當同時考慮QoR和設計工作時，我們發現，使用HLS的設計者在每個設計小時的平均性能是RTL的4.4倍。我們自己的案例研究通過報告生產率提高6.0倍來支持這一論點。因此，當上市時間成為主要問題並且沒有迫切需要獲得產品的最終性能或最小資源消耗時，HLS是一個特別好的選擇。當對現有設計進行架構更改時，HLS還可以節省大量時間。

在我們的參考文獻中，經常缺少信息，這使得HLS與RTL的比較更具挑戰性。因此，我們的案例研究還展示了報告同一應用程序的HLS和RTL結果的最佳實踐。最好，測試組應該比我們可以使用的更大，但是我們的測試用例仍然顯示了我們建議在此類研究中報告的基本細節。將來，可以由具有更多硬件專業知識的測試小組進行類似的案例研究。儘管本文顯示出硬件經驗有限的人可以輕鬆採用HLS併產生良好的結果，但有趣的是，看看硬件工程師作為測試人員的生產率和QoR差異如何表現。

在調查的論文中，經常也缺少驗證工作量的比較。大多數情況下，關於HLS工具如何允許在RTL驗證中方便地使用行為測試平臺的簡短說明。由於驗證是任何硬件項目的重要組成部分，因此這是對HLS研究狀態的重大監督。因此，將來，應該對HLS與RTL驗證流程進行更多的定量研究。

我們還對文獻進行了調查，以提出建議並完成研究，以改善HLS的QoR和驗證流程。我們發現了許多論文，這些論文展示了通過在HLS設計流程中添加新步驟或使DSE自動化來顯著改善QoR的方法。

過去十年中，隨著HLS工具取得的進展，我們可以得出結論，該方法已為業界在原型設計和快速產品開發中採用做好了準備。如果下一代HLS工具可以完全彌補QoR差距，那麼HLS將成為新的標準設計方法，而RTL可以針對與當今軟件開發中的彙編語言類似的有限微調。

後續文章中我們會討論可編程網絡中使用的各種高級語言。

參考文獻請下載原文查看，原文鏈接：https://ieeexplore.ieee.org/abstract/document/8356004。