HLS与RTL语言的使用最佳实践研究

为了提高设计数字硬件组件的效率，高层综合（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的承诺很多。

通过提高抽象级别，可以减少最初的设计工作量。设计人员可以集中精力描述系统的行为，而不必花费时间来实现微体系结构的细节。在更高的抽象级别上，也不太可能在代码中引入错误。

验证被加速。通常可以使用软件验证工具来验证设计的行为，该软件验证工具比RTL仿真工具更容易使用。此外，HLS工具的RTL输出可以使用原始的行为测试台进行验证，因为该工具可以检查两个模型的结果是否相同。

设计空间探索（DSE）更快。可以通过在HLS工具中进行选择来探索微体系结构，这些选择几乎不需要修改代码。因此，可以在数小时内探索几种转换，例如流水线化和各种循环展开因子。这是对RTL方法论的巨大改进，在RTL方法论上，此类更改将需要对源代码进行重大修改。

定位新平台非常简单。如果目标平台发生变化，则HLS工具能够相应地修改RTL输出。例如，如果新平台具有不同的时钟频率，则HLS工具将根据新频率重新安排操作。

软件工程师可以访问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和开发工作。本文有四个主要贡献。

对科学文章中报道的HLS和RTL流程的QoR和设计工作的比较分析。

案例研究介绍了将HLS和RTL方法与使用这两种流程来实现HEVC / H.265视频编码器的一部分的测试组进行比较的最佳实践。

文献调查表明了改善HLS的研究方向和方法。

关于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工作流程进行比较研究。

应该使用一组人来实施相同的设计，以减少设计师体验这两种流程的影响。

除非许可协议禁止，否则应报告使用的HLS工具和语言。这些选择已显示出会影响QoR [12] – [13] [14]。

当进行专注于QoR差异的研究时，在RTL和HLS设计中应使用相同的微体系结构。但是，如果重点是生产力或HLS的可用性，则可以取消此限制。

对于FPGA实施，应报告确切的FPGA芯片模型和版本以允许复制结果。

应报告每个设计师的时间使用情况。此外，应该报告每个工作阶段所花费的时间，以便更深入地了解使用HLS和RTL版本最耗时的部分。

应该报告输入代码的行，以显示应用程序的大小和复杂性。

除了基本的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可以针对与当今软件开发中的汇编语言类似的有限微调。 后续文章中我们会讨论可编程网络中使用的各种高级语言。

　　审核编辑：郭婷