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

引言

數(shù)十年來，寄存器傳輸級別（RTL）一直是描述超大規(guī)模集成（VLSI）系統(tǒng)及其組成知識產(chǎn)權(quán)塊的主要方法。盡管RTL工具只是逐步發(fā)展的，但VLSI系統(tǒng)的復雜性卻呈指數(shù)級增長，這使設(shè)計和驗證過程成為生產(chǎn)力的瓶頸[1]。

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

HLS的承諾很多。

通過提高抽象級別，可以減少最初的設(shè)計工作量。設(shè)計人員可以集中精力描述系統(tǒng)的行為，而不必花費時間來實現(xiàn)微體系結(jié)構(gòu)的細節(jié)。在更高的抽象級別上，也不太可能在代碼中引入錯誤。

驗證被加速。通?？梢允褂密浖炞C工具來驗證設(shè)計的行為，該軟件驗證工具比RTL仿真工具更容易使用。此外，HLS工具的RTL輸出可以使用原始的行為測試臺進行驗證，因為該工具可以檢查兩個模型的結(jié)果是否相同。

設(shè)計空間探索（DSE）更快。可以通過在HLS工具中進行選擇來探索微體系結(jié)構(gòu)，這些選擇幾乎不需要修改代碼。因此，可以在數(shù)小時內(nèi)探索幾種轉(zhuǎn)換，例如流水線化和各種循環(huán)展開因子。這是對RTL方法論的巨大改進，在RTL方法論上，此類更改將需要對源代碼進行重大修改。

定位新平臺非常簡單。如果目標平臺發(fā)生變化，則HLS工具能夠相應(yīng)地修改RTL輸出。例如，如果新平臺具有不同的時鐘頻率，則HLS工具將根據(jù)新頻率重新安排操作。

軟件工程師可以訪問HLS。RTL設(shè)計需要了解VHDL和Verilog等語言，而HLS工具通常使用熟悉的語言，如C / C ++。HLS工具可以處理大多數(shù)特定于硬件的實現(xiàn)細節(jié)，因此大大降低了軟件工程師處理硬件項目的門檻。也就是說，為了獲得最佳結(jié)果，在使用HLS時，硬件專業(yè)知識仍然有用。

這些好處加在一起，減少了設(shè)計和驗證時間，降低了開發(fā)成本，并降低了進行硬件項目的門檻。因此，縮短了產(chǎn)品上市時間，并且在異構(gòu)系統(tǒng)上使用硬件加速已成為更具吸引力的選擇。

現(xiàn)場可編程門陣列（FPGA）的興起也是HLS的推動因素。FPGA是HLS設(shè)計的理想平臺，因為它們可以快速進行原型設(shè)計，具有快速的設(shè)計周期并且具有固有的可重新編程性?，F(xiàn)代的HLS工具通常包含用于設(shè)計目標的廣泛的FPGA技術(shù)庫。

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

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

對科學文章中報道的HLS和RTL流程的QoR和設(shè)計工作的比較分析。

案例研究介紹了將HLS和RTL方法與使用這兩種流程來實現(xiàn)HEVC / H.265視頻編碼器的一部分的測試組進行比較的最佳實踐。

文獻調(diào)查表明了改善HLS的研究方向和方法。

關(guān)于HLS的最新技術(shù)的結(jié)論。

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

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

相關(guān)論文

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

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

應(yīng)用特定指標的性能。

執(zhí)行時間和/或延遲。

目標平臺上可達到的最大時鐘頻率。

專用集成電路（ASIC）上的區(qū)域。

FPGA上的資源使用情況。

能量消耗。

開發(fā)時間。

輸入源代碼（LoC）的行。

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

表一顯示了每年發(fā)表的合格論文數(shù)量。由于每年發(fā)表的論文數(shù)量較少，因此用我們的數(shù)據(jù)來檢查這些年內(nèi)HLS的QoR可能的趨勢是不可行的。對于這類研究來說，較長的年份范圍也是比較好的。

分析

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

表II指標及其在審閱論文中的出現(xiàn)頻率

22篇文章報告了多個應(yīng)用程序或?qū)嶒炘O(shè)置的結(jié)果。在許多作品中，實現(xiàn)了多個不同的應(yīng)用程序，這些應(yīng)用程序經(jīng)常彼此關(guān)聯(lián)（例如[9]–[10][11]）。一些作者比較了不同的HLS工具[12]–[13][14]，而其他作者比較了各種微體系結(jié)構(gòu)優(yōu)化，例如循環(huán)展開和流水線[15]，[16]或不同的FPGA芯片[17]和[18]。。因此，數(shù)據(jù)集比僅合格論文所建議的數(shù)量要大。為簡便起見，我們將分別稱為這些結(jié)果申請表，無論它們是基于實際的不同應(yīng)用，HLS工具，F(xiàn)PGA芯片還是其他版本。表II的第三列顯示了報告給定指標的應(yīng)用程序總數(shù)。

比較HLS和RTL方法時，開發(fā)時間非常受關(guān)注。但是，只有三分之一的論文報告了開發(fā)時間，這在忽略它的文章中被視為一個缺陷。在各種QoR指標中，報告的FPGA資源使用率要比性能值高。只有四篇論文針對ASIC實現(xiàn)（而非FPGA），因此沒有足夠的數(shù)據(jù)來比較ASIC面積結(jié)果。功耗也是如此。 幾乎所有論文都報告了使用的HLS工具。其余作品沒有理由不透露信息，但許可協(xié)議可能是原因。但是，即使那些文章也提到了HLS輸入語言。 表III匯總了所使用的HLS工具。第二列告訴每個工具出現(xiàn)的次數(shù)，第三列告訴他們輸入語言。該表表明，至少在學術(shù)界，Vivado HLS（以前稱為自動駕駛儀）是最受歡迎的HLS工具。所有其他工具僅獲得分散的使用。Vivado之所以受歡迎，可能是因為Xilinx是領(lǐng)先的FPGA供應(yīng)商，其FPGA設(shè)計套件包括Vivado HLS。大量使用過的HLS工具還說明了該領(lǐng)域的相對不成熟。

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

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

研究結(jié)果比較

A.關(guān)于QoR指標 FPGA的基本構(gòu)建塊是可配置邏輯塊（CLB）或邏輯陣列塊（LAB），具體取決于FPGA供應(yīng)商和器件。CLB / LAB由幾個邏輯單元組成，這些邏輯單元可以稱為邏輯單元（LC），邏輯元件（LE）或自適應(yīng)邏輯模塊。這些邏輯單元由查找表和觸發(fā)器組成。綜述的論文通常在為FPGA合成應(yīng)用程序時報告這些圖之一。就本文而言，與報告哪個數(shù)字無關(guān)，因為我們對HLS和RTL之間的資源使用比率感興趣。因此，我們將所有這些資源指標歸為同一術(shù)語，稱為基本FPGA資源。 FPGA還包含其他資源，例如DSP塊和片上塊RAM（BRAM）存儲器，如果沒有FPGA供應(yīng)商的足夠數(shù)據(jù)，則無法將其轉(zhuǎn)換為CLB等效項。這將需要知道確切的FPGA芯片類型，但是只有大約60％的審閱論文對此進行了報告，而其他論文僅陳述了所使用的FPGA系列。因此，我們沒有一種通用的方法將所有資源指標組合為一個資源使用價值，可以在各個應(yīng)用程序之間進行比較。因此，我們放棄了這種方法，而是選擇CLB或其組成部分作為資源使用情況比較的基礎(chǔ)。 審閱的論文還根據(jù)實現(xiàn)的應(yīng)用程序使用了各種不同的性能指標。這些可以分為四類：1）性能；2）執(zhí)行時間；3）延遲；4）最大頻率。在這種情況下，可以根據(jù)應(yīng)用以幾種方式解釋性能。例如，對于視頻編碼器，這表示每秒的幀數(shù)，對于加密模塊，則表示每秒的加密位。對于具有清晰開始和結(jié)束的應(yīng)用程序，通常會報告執(zhí)行時間，有些論文會報告延遲，即處理樣本的時鐘周期數(shù)。最常報告的性能指標是可以在目標FPGA上調(diào)度應(yīng)用程序的最大頻率。

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

B 數(shù)值分析 表IV收集了我們發(fā)現(xiàn)的數(shù)值匯總數(shù)據(jù)。?表示報告了相應(yīng)數(shù)據(jù)的申請數(shù)量。第三列報告HLS和RTL結(jié)果之間的比率平均值。對于除DSP模塊和BRAM以外的所有值，我們使用幾何平均值而不是算術(shù)平均值，因為由于應(yīng)用范圍廣泛，每個類別中的值可能相差一個數(shù)量級。對于DSP模塊和BRAM，由于數(shù)據(jù)集中的零，因此無法計算幾何平均值，因此使用了算術(shù)平均值。粗體均值支持HLS，而非粗體均值支持RTL。第四列顯示幾何標準偏差（GSD）。請注意，它是一個乘法值：下限是通過除以GSD獲得的，上限是通過乘以GSD獲得的。

表IV論文數(shù)值數(shù)據(jù)摘要

不出所料，HLS在開發(fā)時間和源代碼行方面均優(yōu)于RTL。平均開發(fā)時間僅為相應(yīng)RTL應(yīng)用程序的三分之一。我們還檢查了HLS與RTL的開發(fā)時間比例與絕對開發(fā)時間的關(guān)系看看項目規(guī)模是否對比率有影響，但沒有相關(guān)性。因此，對于大型和小型應(yīng)用程序來說，減少的開發(fā)時間似乎是相同的。另一方面，分別與代碼大小的比較表明，對于較大的應(yīng)用程序（1000 LoC或更多），HLS代碼似乎比RTL代碼更緊湊。實際上，在所有情況下，HLS LoC比RTL LoC多，代碼大小小于250 LoC。使用較小的代碼大小，非行為代碼將在總代碼中占相對較大的部分，這似乎有利于RTL。 在性能和執(zhí)行時間上，HLS設(shè)計的平均水平明顯較差，但在延遲和最大頻率方面，差異不那么明顯。HLS方法還會浪費基本資源：平均而言，HLS使用的基本FPGA資源比RTL多41％。使用BRAM和DSP模塊，結(jié)果是矛盾的?；趫蟾嬉咽褂玫腂RAM塊數(shù)量的論文，HLS似乎更有效地使用它們，但是對于報告以千位為單位的BRAM使用情況的論文，RTL勝出。在DSP塊使用中，HLS和RTL看起來很相似。 我們還研究了HLS輸入語言如何影響QoR。在[19]，HLS工具根據(jù)其描述輸入的樣式分為五類：諸如框架的硬件描述語言（HDL），基于C的框架，基于高級語言（HLL）的框架（這些是高度抽象的，通常是對象面向語言），基于模型的框架（使用可執(zhí)行規(guī)范，例如NI LabView和MATLAB HDL Coder）以及基于CUDA / OpenCL的框架。在本文中，我們發(fā)現(xiàn)有5個使用HDL的應(yīng)用程序，例如77個基于C的應(yīng)用程序，10個基于HLL的應(yīng)用程序，六個基于模型的應(yīng)用程序和11個基于CUDA / OpenCL的框架。由于基于C的框架以外的框架僅接受分散的用法，因此不明智地將所有類別相互比較。相反，我們比較了基于C的框架和所有其他框架的QoR。結(jié)果顯示在表V中，其中?表示可比較結(jié)果的數(shù)量。似乎基于C的框架所產(chǎn)生的設(shè)計性能要比其他框架差，但可以節(jié)省基本資源的使用。進一步研究數(shù)據(jù)，我們注意到基于CUDA / OpenCL的框架特別消耗資源（3.56×）并產(chǎn)生了最差的效果（0.56×）。

表V按框架類型比較QoR

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

圖1. 不同應(yīng)用程序的性能和基本資源使用率之間的HLS與RTL之比的散布圖。

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

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

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

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

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

圖4-不同應(yīng)用程序的HLS / RTL開發(fā)時間比率。 同樣，圖5描繪了HLS和RTL設(shè)計之間的LoC比。在這里，HLS的主導地位不那么突出，但仍然很重要。在75％的情況下，HLS LoC小于RTL LoC。

圖5-不同應(yīng)用的HLS / RTL LoC比。

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

圖6.-HLS / RTL（a）性能比（b）基本資源使用率與HLS LoC的關(guān)系。

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

圖7-不同應(yīng)用的HLS到RTL的相對生產(chǎn)率。

測試研究

這項調(diào)查表明，許多先前的工作報告的HLS與RTL比較結(jié)果均不夠充分，這也使我們的數(shù)據(jù)收集變得復雜。因此，我們組織了一個案例研究，以展示在建立適當?shù)臏y試以進行比較和報告結(jié)果方面的最佳實踐。案例研究的第二個目的是檢查HLS和RTL流量從用戶的角度來看有何不同，以及流量的相對生產(chǎn)率是多少。以前的大多數(shù)研究只集中在QoR差異上。 案例研究是為實現(xiàn)2D離散余弦變換（DCT）算法[20]8×8高效視頻編碼（HEVC）[21]編碼器中使用的剩余塊。選擇DCT是因為它眾所周知并且具有適當?shù)膹碗s性。 A.測試組 該測試小組由六名具有數(shù)字設(shè)計和編程基礎(chǔ)知識的參與者組成。如表VI所示，他們以前已經(jīng)編寫了1k到100k行的C或C ++。平均而言，他們在工作或業(yè)余項目中大約有15個月的編程經(jīng)驗。參加者在硬件設(shè)計方面的經(jīng)驗要少得多，他們平均只有1000行VHDL或Verilog代碼，并且在此類項目中的經(jīng)驗為三個月。在進行這項研究之前，只有一名參與者完成了有關(guān)HLS的小教程，從而使該實驗成為了其余部分中HLS的首次介紹。 表VI測試小組的背景經(jīng)驗

我們選擇了硬件經(jīng)驗有限但軟件經(jīng)驗適中的參與者，因為HLS承諾會隱藏特定于硬件的實施細節(jié)。因此，習慣于在軟件項目中編寫行為描述的程序員是HLS的理想讀者。確實，HLS的試金石測試是，在設(shè)計相對簡單的硬件模塊時，此類用戶可以毫不費力地產(chǎn)生可接受的結(jié)果。為了獲得足夠的HLS背景知識，參與者自學了HLS基礎(chǔ)知識，并進行了五個小練習，以實現(xiàn)FPGA音頻編解碼器的各個部分。以前，他們使用VHDL RTL進行了相同的練習。 B.測試用例 在HEVC編碼器中，DCT用于轉(zhuǎn)換8×8空間域殘差塊成8×8變換域系數(shù)（tcoeff）矩陣。眾所周知的行列算法[20]在兩個連續(xù)的階段中執(zhí)行具有可分離的1-D轉(zhuǎn)換的這些2-D轉(zhuǎn)換。首先將變換應(yīng)用于殘差塊的每一行以生成中間矩陣，然后將其應(yīng)用于中間矩陣的每一列以生成最終的變換系數(shù)矩陣。 參與者被分配為實現(xiàn)此2-D DCT硬件單元8×8帶有RTL（VHDL或Verilog）和HLS（帶有Mentor Graphics的Catapult-C版本8.2 m UV的C / C ++）的剩余塊。Catapult-C支持從編寫原始源代碼到生成和驗證RTL代碼的整個設(shè)計流程。在本文中，沒有進行物理的FPGA實現(xiàn)，但僅使用綜合結(jié)果來獲得QoR數(shù)據(jù)。由于我們對HLS與RTL的相對結(jié)果感興趣，因此省略了執(zhí)行布局和路線（P＆R），并且P＆R不會顯著影響該比率。 提供的DCT參考包括HEVC規(guī)范及其在HEVC參考編碼器中的實現(xiàn)[22]。與會者還獲得了現(xiàn)成的SystemC測試平臺以及對接口的要求，以使測試平臺能夠正常工作。接口要求包括輸入和輸出數(shù)據(jù)總線的寬度以及相關(guān)的控制信號。RTL和HLS版本使用相同的測試平臺。它為第一遍生成隨機殘差值，并為第二遍執(zhí)行必要的轉(zhuǎn)置。成功實施的條件是要通過測試平臺驗證。 還指示參與者將工作時間分配到五個類別：1）設(shè)計；2）實施；3）搜索信息；4）模擬；5）調(diào)試。他們被允許選擇是先實施HLS還是RTL版本，或者同時實施兩者。 C.結(jié)果 表VII顯示了各個測試人員執(zhí)行RTL和HLS的面積和速度數(shù)字。HLS / RTL比率顯示HLS和RTL結(jié)果之間的比率。粗體字表示HLS流量何時達到更好的結(jié)果。使用參與者報告的輸出系數(shù)，等待時間，吞吐量和頻率，將速度計算為每秒百萬個變換系數(shù)。 表VIIRTL和HLS設(shè)計的面積和性能圖

有四名測試人員開始了RTL實施工作。所有參與者都使用VHDL而不是Verilog編寫了RTL代碼。即使使用RTL實現(xiàn)了最小的面積和最高的頻率，總體趨勢是，參與者可以使用HLS工具獲得略小的面積和略高的時鐘頻率。此外，HLS設(shè)計已經(jīng)結(jié)束2.5×速度與RTL設(shè)計一樣快，這也影響了速度與面積之比。例如，第4個人在使用HLS的所有設(shè)計中都獲得了最佳的速度與面積之比。另一方面，第3個人是唯一使用RTL獲得更快的速度與面積比的人。所有測試人員都使用多級結(jié)構(gòu)來計算RTL代碼中的DCT，但是他們都沒有實現(xiàn)更復雜的狀態(tài)機以對連續(xù)輸入使用級流水線。在RTL情況下，缺少流水線會降低吞吐量。相比之下，與RTL相比，所有人都可以在HLS中使用循環(huán)展開和流水線操作來獲得更好的吞吐量值。 表VIII列出了HLS和RTL方法的生產(chǎn)率值。使用HLS工具，所有參與者的生產(chǎn)力顯然都更好，并且HLS的平均生產(chǎn)力高達RTL的6.0倍。因此，它甚至高于調(diào)查結(jié)果。我們可以推測，如果人們在其RTL實現(xiàn)中實現(xiàn)了階段流水線工作，生產(chǎn)力將如何改變。生產(chǎn)力水平不太可能轉(zhuǎn)移到支持HTL之上的RTL，因為時間使用量會隨著吞吐量的增加而增加。 表VIIIHLS和RTL生產(chǎn)率

表IX論文摘要

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

圖8使用RTL和HLS的不同類別的最大，最小和平均時間使用情況。 結(jié)論是，使用HLS的所有參與者的生產(chǎn)率都高于使用RTL的生產(chǎn)率。盡管小組規(guī)模很小，并且人員的硬件背景非常相似，但這項研究表明，采用HLS比RTL更容易，并且對于擁有大多數(shù)軟件設(shè)計經(jīng)驗的人員來說，更快地收到更好的結(jié)果。該結(jié)果強調(diào)了以下事實：HLS對于想要實施例如硬件加速器的軟件工程師是有用的工具。 應(yīng)該注意的是，我們的結(jié)果不同于典型的調(diào)查研究，后者的RTL的QoR優(yōu)于HLS的QoR。對此的可能解釋是，在接受調(diào)查的作品中，設(shè)計師比我們的測試人員擁有更多的硬件專業(yè)知識。另一方面，我們的案例研究與有關(guān)生產(chǎn)率的調(diào)查文獻一致，這有利于HLS。 D.測試人員的反饋 完成測試任務(wù)后，向參與者詢問HLS和RTL設(shè)計流程的優(yōu)缺點，最后他們必須從中選擇自己喜歡的。答案在HLS和RTL流之間平均分配（3–3）。 與HLS相比，偏愛RTL的人們希望為HLS工具提供更多的開源支持，因為流程高度依賴于工具。這將允許更多的業(yè)余愛好者使用HLS工具。一些測試人員還希望在HLS工具中對周期精度方面的結(jié)果RTL進行更多控制。對于他們來說，RTL更容易進行微調(diào)，并且可以使他們更好地了解當前的問題。 與HTL相比，HLS的支持者更喜歡HLS的易用性，HLS工具的職責是保留不必要的細節(jié)，如自動I / O握手和流水線支持。這使參與者可以集中精力定義行為描述。他們還認為RTL更加耗時，需要更多的計劃，并且很難進行重新設(shè)計。 測試人員的總體結(jié)論是，在嵌入式編程中，HLS和RTL與C和匯編語言相比。他們認為，設(shè)計人員寧愿使用HLS（可用的最高抽象級別），而較低級別的RTL僅應(yīng)在周期關(guān)鍵型應(yīng)用程序中使用，或者應(yīng)能夠顯著提高性能。 E.最佳做法 我們使用文獻調(diào)查和本案例研究來總結(jié)以下最佳實踐，以對RTL和HLS工作流程進行比較研究。

應(yīng)該使用一組人來實施相同的設(shè)計，以減少設(shè)計師體驗這兩種流程的影響。

除非許可協(xié)議禁止，否則應(yīng)報告使用的HLS工具和語言。這些選擇已顯示出會影響QoR [12]–[13][14]。

當進行專注于QoR差異的研究時，在RTL和HLS設(shè)計中應(yīng)使用相同的微體系結(jié)構(gòu)。但是，如果重點是生產(chǎn)力或HLS的可用性，則可以取消此限制。

對于FPGA實施，應(yīng)報告確切的FPGA芯片模型和版本以允許復制結(jié)果。

應(yīng)報告每個設(shè)計師的時間使用情況。此外，應(yīng)該報告每個工作階段所花費的時間，以便更深入地了解使用HLS和RTL版本最耗時的部分。

應(yīng)該報告輸入代碼的行，以顯示應(yīng)用程序的大小和復雜性。

除了基本的QoR結(jié)果外，還應(yīng)報告每個設(shè)計時間的性能，以顯示HLS和RTL流程之間的生產(chǎn)率差異。

彌補質(zhì)量差距

我們的調(diào)查表明，對于任何給定的應(yīng)用程序，HLS和RTL方法之間通常仍然存在QoR差距，通常更傾向于RTL。現(xiàn)有大量文獻已經(jīng)認識到這一差距并提出了縮小差距的方法。在本節(jié)中，我們將對這些文獻進行調(diào)查，以向HLS研究人員和開發(fā)人員重點介紹。此外，我們將對對現(xiàn)有HLS流程進行新穎改進的論文進行審查。 A.工具開發(fā)人員的研究方向 Sun 等 [8]為HLS工具開發(fā)人員集中精力提供了一些建議。他們指出，資源共享和調(diào)度是當前HLS工具仍在努力的HLS技術(shù)的兩個主要功能。例如，他們演示了當僅需要13個具有最佳共享功能的硬件時，HLS工具會實例化31種特定類型的硬件操作員。他們還注意到，HLS工具混淆了源代碼和生成的硬件之間的關(guān)系，從而使識別代碼的次優(yōu)部分變得困難。此外，作者呼吁業(yè)界就HLS的基于C的標準輸入語言達成一致。這將為工具用戶和工具本身提供一種明確的方式來解釋源代碼。 Rupnow 等 [57]在HLS的可用性和QoR方面都有公認的發(fā)展空間。他們的研究使用的是AutoPilot(現(xiàn)為Vivado HLS)，但建議是可推廣的。作者建議對循環(huán)流水線和展開進行自動權(quán)衡分析，以使DSE更快。對于復雜的循環(huán)結(jié)構(gòu)，可能的優(yōu)化組合數(shù)量可能會非常多。此外，作者呼吁支持BRAM端口復制指令，為數(shù)據(jù)流轉(zhuǎn)換提供更強大的功能，并支持2-D訪問模式的流計算。為了改善QoR，他們建議這些工具應(yīng)該檢測單獨的循環(huán)和函數(shù)之間的內(nèi)存級別相關(guān)性，并自動對內(nèi)存訪問進行重新排序，以允許分區(qū)，流傳輸和更好的流水線操作。這些工具還應(yīng)該自動創(chuàng)建緩沖區(qū)，以提高內(nèi)存訪問的重用性。 在[5]中也認識到了優(yōu)化存儲器訪問在高質(zhì)量設(shè)計中的重要性。作者指出，HLS工具通常不支持內(nèi)存層次結(jié)構(gòu)，也不抽象外部內(nèi)存訪問。因此，要求設(shè)計人員注意總線接口和內(nèi)存控制器的細節(jié)，這與行為設(shè)計范式的思想不太吻合。HLS工具應(yīng)向設(shè)計人員隱藏外部存儲器傳輸，以解決此問題。

本文還指出了從順序C / C ++規(guī)范中獲得任務(wù)級并行性的困難，為此作者建議開發(fā)適當?shù)脑O(shè)備中性編程模型。 在[32]中，提出了在HLS工具中缺乏對動態(tài)數(shù)據(jù)結(jié)構(gòu)的支持。作者采用以數(shù)據(jù)流為中心的方式并通過使用動態(tài)內(nèi)存分配的遞歸樹遍歷來實現(xiàn)相同的算法，并觀察到使用后一種方法會明顯降低性能。通過應(yīng)用幾次手動代碼轉(zhuǎn)換，作者可以提高性能，并得出結(jié)論，HLS工具應(yīng)使用動態(tài)數(shù)據(jù)結(jié)構(gòu)自動執(zhí)行類似的優(yōu)化。 B. HLS流程的改進 由于研究文章的作者通常無法訪問商業(yè)HLS工具的源代碼，因此大多數(shù)對HLS結(jié)果進行了改進的論文都是通過在設(shè)計流程中引入新的優(yōu)化步驟來實現(xiàn)的。本節(jié)將回顧一些屬于此類的有希望的結(jié)果。 Josipovic 等[58]提出了使用并行模式模板來根據(jù)目標設(shè)備的屬性來擴展模塊實現(xiàn)，這超出了HLS工具的能力。作者出現(xiàn)了2.8 × 加快了標準HLS工具流程的速度。在[59]中也使用了基于模板的方法，其中使用針對硬件優(yōu)化的通用計算模式的可組合和可參數(shù)化模板來提高性能。為了方便用戶，這些模板可以包含在HLS工具中。 在[60]中，討論了大規(guī)模并行算法中的內(nèi)存訪問瓶頸問題。作者提出了一種算法，該算法可以調(diào)度在不同管線階段訪問的內(nèi)存，從而減少了同時訪問的壓力。他們的方法平均將流水線性能提高了43%，并將存儲庫使用量減少了55%。[61]中討論了另一種減少內(nèi)存訪問開銷的方法。

本文提出了一種新穎的算法，可以在某些區(qū)域約束下選擇性地將陣列定標為片上寄存器。結(jié)果表明性能有了顯著提高。 啟用更高效的HLS的一種方法是通過識別自順序基本操作合并的自定義操作。這降低了合成算法的數(shù)據(jù)流圖的復雜性，從而減少了合成時間并提高了QoR。在[62]中已經(jīng)研究了這種方法，在面積消耗，性能和代碼大小方面實現(xiàn)了顯著的改進。因此，HLS工具應(yīng)包括自定義操作標識作為預(yù)處理步驟。 資源分配和操作綁定是HLS中的兩個基本步驟。因此，它們的有效實施對于實現(xiàn)良好的QoR至關(guān)重要。在[63]中，已經(jīng)研究了寄存器分配的影響。

本文表明，在大多數(shù)情況下，一種簡單的資源分配策略，即每個變量一個寄存器而沒有寄存器共享，可以帶來最佳的QoR結(jié)果。 HLS工具使用軟件編譯器來創(chuàng)建輸入程序的中間表示(IR)。然后在HLS優(yōu)化步驟中使用IR。IR和編譯器選項影響QoR也就不足為奇了。黃等。 [64]研究了不同編譯器選項對QoR的影響，并開發(fā)了一種方法，僅自動選擇可改善QoR的選項，與通常的-O3優(yōu)化水平相比，平均性能提高了16%。 在[65]中，觀察到可以通過合并不同的行為描述而不是分別為每個行為描述執(zhí)行HLS來節(jié)省大量面積。這是因為當HLS工具可以在描述之間共享功能單元時，可以更好地共享FPGA上的功能單元。本文提出了一種在給定的等待時間約束內(nèi)搜索最佳合并的算法。 C.設(shè)計空間探索 HLS工具包含各種指令，可以指導硬件綜合以生成更有效的設(shè)計。這些指令包括流水線化和循環(huán)展開以及數(shù)組分區(qū)等。由于大多數(shù)算法都包含許多循環(huán)和數(shù)據(jù)數(shù)組，因此找到一組Pareto最佳指令設(shè)置可能是一項艱巨的任務(wù)，但這對獲得良好的QoR至關(guān)重要。因此，應(yīng)該自動探索最佳設(shè)置的設(shè)計空間，但是當前領(lǐng)先的HLS工具無法為DSE用戶提供幫助。另一方面，有一些學術(shù)論文研究了HLS中的DSE自動化。 一種簡單的自動迭代DSE方法在[66]中提出。與非引導式HLS流量相比，該方法著重于減小面積，可將QoR提升多達50%。[67]中展示了一種基于自適應(yīng)加窗方法的更復雜的DSE算法。該算法顯示出可以在運行時間和找到最佳QoR之間取得良好的折衷。專門針對具有嵌套循環(huán)的應(yīng)用程序的類似方法已展示了235 × 與詳盡的DSE相比，速度更快，同時獲得了相似的結(jié)果[68]。 在[69]中，基于順序模型的優(yōu)化已應(yīng)用于DSE問題。

本文表明，該方法可以在合理的時間內(nèi)從成千上萬個可能的設(shè)計空間中找到全局最優(yōu)點。在[70]中，在HLS之前添加了輕量級的預(yù)處理步驟以執(zhí)行目標算法的動態(tài)相關(guān)性分析。當將這些機會作為HLS工具的約束條件時，該方法可以公開資源共享機會，從而產(chǎn)生更好的QoR。 在[71]中已經(jīng)討論了找到最佳環(huán)路展開因子的特定但重要的問題。作者已經(jīng)開發(fā)出一種算法，可以在給定的區(qū)域約束內(nèi)找到最佳展開因子，并表明與其他可能的解決方案相比，該算法可以提供最佳性能。 D.驗證 驗證仍然是任何設(shè)計項目中耗時的部分。因此，HLS工具在所有階段都支持驗證流程至關(guān)重要。盡管HLS流程允許對單個模塊進行有效的行為驗證，但仍必須對生成的RTL進行非行為方面的驗證，例如接口綜合結(jié)果和成功的組件集成。HLS之后傳統(tǒng)的RTL驗證比較困難，因為與輸入源代碼[4]，[5]，[8]沒有直接關(guān)系。然而，在許多情況下，使用HLS可以將驗證時間減少一半[72]。 HLS的驗證方面在最近的一篇論文中進行了廣泛的討論[72]。作者指出，邏輯冗余會降低測試覆蓋率，這是HLS的主要問題。邏輯冗余可能出現(xiàn)在源規(guī)范中，但也可能在RTL生成中由HLS工具引入。因此，HLS工具的開發(fā)人員應(yīng)努力消除產(chǎn)生邏輯冗余的趨勢。除此之外，在驗證過程中可以使用正式的工具來識別冗余。

本文還提倡使用源掉毛作為改善HLS的一種方法。它不僅可以用于檢查錯誤源，還可以通過證明FIFO大小等屬性來幫助優(yōu)化設(shè)計。 叢等。 [5]提出了三個值得注意的項目，以使大多數(shù)調(diào)試都可以在行為輸入語言級別上進行，以進行片上驗證：1)以較小的開銷添加調(diào)試邏輯的能力;2)觀察諸如FIFO之類的關(guān)鍵緩沖區(qū)的能力;3)使用源代碼中的斷點觀察硬件塊內(nèi)部狀態(tài)的能力。由于計算機生成的RTL代碼，執(zhí)行HLS后無法在RTL級別上實現(xiàn)這些重要的調(diào)試功能。 除了驗證之外，工程變更單(ECO)還在HLS方面帶來了困難[4]。發(fā)出ECO時，僅需要一些小的增量更改，這些更改通常不會被高級行為描述捕獲。另一方面，已經(jīng)注意到，由于可以廣泛驗證行為源代碼，并且HLS工具確保所生成的RTL是正確的，因此ECO在HLS流中并不常見[66]。

結(jié)論

在本文中，我們檢查了46篇最近的文章，這些文章比較了HLS和RTL設(shè)計流程之間的QoR和設(shè)計工作。由于HLS有望比RTL帶來更高的生產(chǎn)率，因此我們的目的是了解現(xiàn)代HLS工具是否也能夠產(chǎn)生可與手動調(diào)整的RTL設(shè)計競爭的結(jié)果。 我們的調(diào)查表明，即使是最新一代的HLS工具，也無法提供與手動RTL一樣好的性能和資源使用。但是，結(jié)果差異很大，并且在大約40%的評估案例中，HLS被證明等于或優(yōu)于RTL方法。我們自己的案例研究表明，硬件經(jīng)驗有限的設(shè)計人員可以使用HLS獲得更好的結(jié)果，并且性能提高2.5倍，F(xiàn)PGA資源使用率略低。我們還檢查了設(shè)計的大小是否影響了HLS和RTL之間的相對QoR，但沒有發(fā)現(xiàn)相關(guān)性。因此，HLS似乎適合于大小設(shè)計。 在設(shè)計方面，調(diào)查顯示HLS顯然是預(yù)期的領(lǐng)先者。平均而言，HLS設(shè)計時間僅為相應(yīng)RTL設(shè)計時間的三分之一。另外，HLS輸入代碼的大小幾乎減半，平均為RTL代碼大小的52%。當同時考慮QoR和設(shè)計工作時，我們發(fā)現(xiàn)，使用HLS的設(shè)計者在每個設(shè)計小時的平均性能是RTL的4.4倍。我們自己的案例研究通過報告生產(chǎn)率提高6.0倍來支持這一論點。因此，當上市時間成為主要問題并且沒有迫切需要獲得產(chǎn)品的最終性能或最小資源消耗時，HLS是一個特別好的選擇。當對現(xiàn)有設(shè)計進行架構(gòu)更改時，HLS還可以節(jié)省大量時間。

在我們的參考文獻中，經(jīng)常缺少信息，這使得HLS與RTL的比較更具挑戰(zhàn)性。因此，我們的案例研究還展示了報告同一應(yīng)用程序的HLS和RTL結(jié)果的最佳實踐。最好，測試組應(yīng)該比我們可以使用的更大，但是我們的測試用例仍然顯示了我們建議在此類研究中報告的基本細節(jié)。將來，可以由具有更多硬件專業(yè)知識的測試小組進行類似的案例研究。盡管本文顯示出硬件經(jīng)驗有限的人可以輕松采用HLS并產(chǎn)生良好的結(jié)果，但有趣的是，看看硬件工程師作為測試人員的生產(chǎn)率和QoR差異如何表現(xiàn)。 在調(diào)查的論文中，經(jīng)常也缺少驗證工作量的比較。大多數(shù)情況下，關(guān)于HLS工具如何允許在RTL驗證中方便地使用行為測試平臺的簡短說明。由于驗證是任何硬件項目的重要組成部分，因此這是對HLS研究狀態(tài)的重大監(jiān)督。因此，將來，應(yīng)該對HLS與RTL驗證流程進行更多的定量研究。 我們還對文獻進行了調(diào)查，以提出建議并完成研究，以改善HLS的QoR和驗證流程。我們發(fā)現(xiàn)了許多論文，這些論文展示了通過在HLS設(shè)計流程中添加新步驟或使DSE自動化來顯著改善QoR的方法。 過去十年中，隨著HLS工具取得的進展，我們可以得出結(jié)論，該方法已為業(yè)界在原型設(shè)計和快速產(chǎn)品開發(fā)中采用做好了準備。如果下一代HLS工具可以完全彌補QoR差距，那么HLS將成為新的標準設(shè)計方法，而RTL可以針對與當今軟件開發(fā)中的匯編語言類似的有限微調(diào)。 后續(xù)文章中我們會討論可編程網(wǎng)絡(luò)中使用的各種高級語言。

審核編輯：郭婷