HLS综述笔记｜Are We There Yet? A Study on the State of High-Level Synthesis

Are We There Yet? A Study on the State of High-Level Synthesis

目录

Are We There Yet? A Study on the State of High-Level Synthesis

1. Introduction

2. Quanlifying Papers

3. Meta-Analysis

4. Comparative Study Results and Analysis

A. On the QoR Metrics

B. Numerical Analysis

C. Comparisons Between Resource Usage and Performance

D. Comparisons Based on Design Effort

5. Test Group Study

A. Test Group

B. Test Case

C. Results

D. Feedback From the Test Persons

E. Best Practices

6. Closing the Quality Gap

A. Research Directions for Tool Developers

B. Improvements to the HLS Flow

C. Design Space Exploration

D. Verification

SUMMARY of Reviewed Papers

---

1. Introduction

HLS 的优点：

1. 利用提高抽象级别，减少初始设计工作量，设计人员可以集中精力描述系统的行为，而不必花费时间实现微架构细节。在更高的抽象级别上，引入代码错误的可能性也较小。
2. 验证加速。设计的行为通常可以使用比RTL仿真工具更快且更简单的软件验证工具进行验证。此外，HLS工具的RTL输出可以通过使用原始行为测试台来验证，因为工具可以检查两个模型的结果是否相同。
3. 设计空间探索（DSE）更快。可以通过在HLS工具中进行选择来探索微架构，这些选择对代码需要很少或没有修改。因此，可以在几个小时内探索多个转换，例如流水线和各种循环展开因子。这是与RTL方法学相比的巨大改进，因为这些更改需要对源代码进行重大修改。
4. HLS可以提高生产力，因为它可以自动生成硬件代码，从而减少了手动编写RTL代码的工作量。
5. HLS可以提高可移植性，因为它可以将代码从一种硬件平台移植到另一种硬件平台，而无需进行重大修改

2. Quanlifying Papers

最近46篇比较高级综合（HLS）和寄存器传输级（RTL）设计流程在相同应用上质量和开发工作量差异的论文。这些论文被用于本研究中，以提供HLS和RTL流程的质量和生产力比较分析。这些论文是根据一定的标准进行筛选的，包括列出HLS和RTL版本应用的以下指标之一或多个：应用特定度量的性能、执行时间和/或延迟、目标平台上的最大可达时钟频率、应用特定集成电路（ASIC）上的面积、FPGA上的资源使用、功耗、开发时间和输入源代码行数（LoC）。

3. Meta-Analysis

对所审查的论文中的感兴趣指标和其出现频率进行总结，提供了一个汇总表格（Table II），其中列出了所关注的指标及其在审查论文中的出现频率。总体而言，审查的论文在实验设置和结果报告方面存在很大的差异。该表格仅计算那些以绝对值或百分比的形式报告结果的论文。不精确的值，例如“执行时间小于100毫秒”，被排除在定量分析之外。

Table 2 显示了论文报告的performance metrics.

        结论：很多论文没有报告开发需要的时间(development time)，算是一种缺陷。几乎所有论文都报告了HLS input tools.

 

Table 3 显示了论文使用的HLS工具

        结论：Vivado HLS（以前称为 Autopilot）是最受欢迎的 HLS 工具，至少在学术界是如此。所有其他工具的使用率都很低

在 46 项合格作品中，39 项使用自制的 RTL 实现与 HLS 进行比较，7 项引用了其他研究小组的 RTL 结果。还有一些作品本应符合本文的要求，但它们引用了与 RTL 实现不兼容的论文，因此被排除在外。例如，用于 RTL 的 FPGA 芯片来自不同的系列，因此无法进行公平的资源 比较。

4. Comparative Study Results and Analysis

对高级综合（HLS）和寄存器传输级（RTL）设计流程在相同应用上质量和生产力差异的比较研究结果和分析。

A. On the QoR Metrics

我们感兴趣的是 HLS 和 RTL 之间的资源使用比例。因此，我们将所有这些资源指标归为同一个术语，即 FPGA 基本资源。

常用的QoR metrics:

1. performance （对每个应用不一样，比如对视频编码器来说是帧数）

2. execution time

3. latency

4. maximum frequency (最常报告的性能指标）

本综述按照上述顺序排列优先级，对于报告了很多指标的论文，优先报告优先级高的。

B. Numerical Analysis

N 表示报告了相应数据的应用数量。第三列报告了 HLS 和 RTL 结果之间比率的平均值。

HLS 在开发时间和源代码行数方面都优于 RTL。平均开发时间仅为相应 RTL 应用程序的三分之一。在性能和执行时间方面，HLS 设计的平均水平明显较低，但在延迟和最大频率方面，差异并不明显。HLS 使用的 FPGA 基本资源平均比 RTL 多 41%。对于 BRAM 和 DSP 块，结果是矛盾的。

HLS 工具根据其描述输入的风格分为五类，（-x 是统计使用该框架的paper数量）

• 类似硬件描述语言（HDL）的框架 - 5
• 基于 C 语言的框架 - 77
• 基于高级语言（HLL）的框架（这些都是高度抽象的，通常是面向对象的语言） - 10
• 基于模型的框架（使用可执行规格，例如 NI LabView 和 MATLAB HDL Coder）- 6
• 基于 CUDA/OpenCL 的框架 - 11

我们比较了基于 C 的框架和所有其他框架的 QoR。其他框架相比，基于 C 的框架设计的性能似乎更差，但在基本资源使用方面却更省。进一步研究数据，我们注意到基于 CUDA/OpenCL 的框架特别耗费资源（3.56 倍），性能最差（0.56 倍）。

C. Comparisons Between Resource Usage and Performance

图1 显示每个应用程序的相对 HLS/RTL 性能与相对 HLS/RTL 基本资源使用情况的对比。

        结论：在绝大多数情况下，HLS 和 RTL 的性能和基本资源使用量差异相对较小。有时候 RTL 在这两方面都比 HLS 更胜一筹。

图 2 显示了 HLS 应用程序（"+"）和 RTL 应用程序（"x"）的绝对性能和基本面积使用值。

        结论：平均而言，HLS 和 RTL 的 QoR 没有本质区别，但 RTL 的 QoR 稍好一些。

图 3 试图解释 HLS/RTL 的相对性能与基本资源使用的绝对数量之间是否存在任何关联

        结论：设计的大小并不影响 HLS 工具优化性能的能力。

D. Comparisons Based on Design Effort

图 4 显示了已报告开发时间的应用程序的 HLS/RTL 开发时间比率。

除三个案例外，其他所有案例的比率都小于 1，72% 的案例小于 0.5。HLS 开发时间大于 RTL 开发时间的三个应用来自同一著作[13]。作者指出，开发时间的差异是由于学习使用 HLS 工具所花费的时间，以及需要修改参考 C++ 源代码才能达到所需的吞吐量。

图 5 显示了已报告Line of Code (LoC) 的应用程序的 HLS/RTL LoC比率。

图 5 描述了 HLS 和 RTL 设计之间的 LoC 比率。在这里，HLS 的优势不那么突出，但仍然很重要。在 75% 的情况下，HLS LoC 小于 RTL LoC。

图 6 LoC 中应用程序的大小与 HLS/RTL 性能之间可能存在的相关性

代码大小与基本资源使用率也不相关。综合来看，图 3 和图 6 表明，应用程序的复杂性对 HLS 与 RTL 的相对性能或基本资源使用率没有影响。然而，如图 6 所示，论文中介绍的大多数应用程序的 LoC 都很小。由于缺乏数据，我们没有对大型应用的相关行为进行研究。

图 7 显示了所有报告了性能和开发时间的应用的相对生产率，方法是用 HLS/RTL 性能除以开发时间比率。

数值大于 1 表示 HLS 方法每设计小时的性能高于 RTL。平均值为 4.4。使用 HLS 工具，设计人员平均每设计小时可获得更高的性能。

5. Test Group Study

找了6个人来看HLS开发到底怎么样。

案例研究是针对高效视频编码（HEVC）[21] 编码器中使用的 8 × 8 残差块实施 2-D 离散余弦变换（DCT）[20] 算法。之所以选择 DCT，是因为它广为人知，而且复杂度适合本文。

A. Test Group

测试组由六名具有数字设计和编程基础知识的学员组成。如表 VI 所示，他们以前编写过 1k 至 100k 行的 C 或 C++ 程序。他们平均有 15 个月的工作或业余项目编程经验。参与者在硬件设计方面的经验要少得多，他们平均编写过 1k 行 VHDL 或 Verilog 代码，并有 3 个月的此类项目经验。只有一名参与者在本研究之前使用 HLS 做了一个小教程，因此本实验是其他参与者第一次接触 HLS。

我们选择了硬件经验有限但软件经验适中的参与者，因为 HLS 可以隐藏特定硬件的实现细节。因此，习惯于在软件项目中编写行为描述的专业人员是 HLS 的理想受众。事实上，HLS 的试金石就是让这些用户在设计相对简单的硬件模块时，毫不费力地获得可接受的结果。

为了获得足够的 HLS 背景知识，学员们自学了 HLS 基础知识，并进行了五个小练习，以实现 FPGA 音频编解码器的部分功能。在此之前，他们已经使用 VHDL RTL 完成了同样的练习。

B. Test Case

参与者还获得了一个现成的 SystemC 测试台和接口要求，以便测试台在不做修改的情况下工作。接口要求包括输入和输出数据总线以及相关控制信号的宽度。RTL 和 HLS 版本使用了相同的测试台。第一次测试生成随机残差值，第二次测试进行必要的转置。成功实施的条件是通过测试台验证。 参与者还被要求将其工作时间分配为五个类别： 1) 设计；2) 实现；3) 搜索信息；4) 模拟；5) 调试。他们可以选择先实施 HLS 版本还是 RTL 版本，或者同时实施两个版本。

C. Results

所有人都能在 HLS 中使用循环解卷和流水线，从而获得比 RTL 高得多的吞吐量。

D. Feedback From the Test Persons

完成测试作业后，参与者被问及 HLS 和 RTL 设计流程的优缺点，最后他们必须从中选出自己最喜欢的流程。HLS 和 RTL 流程的答案各占一半（3-3）。 支持 RTL 而非 HLS 的人希望 HLS 工具能获得更多开源支持，因为 HLS 流程高度依赖于工具。这将使更多业余爱好者使用 HLS 工具。一些测试人员还希望 HLS 工具能在周期精度方面对生成的 RTL 进行更多控制。对他们来说，RTL 更易于微调，而且能让他们更好地理解手头的问题。

E. Best Practices

进行 RTL 和 HLS 工作流程对比研究的最佳实践：

1. 应由一组人员实施相同的设计，以减少设计人员在两种流程中的经验影响。
2. 应报告所使用的 HLS 工具和语言，除非许可协议不允许这样做。这些选择已被证明会影响 QoR [12]-[14]。
3. 在进行以 QoR 差异为中心的研究时，RTL 和 HLS 设计中应使用相同的微体系结构。但是，如果重点是 HLS 的生产率或可用性，则可以取消这一限制。
4. 对于 FPGA 实现，应报告准确的 FPGA 芯片模型和版本，以便复制结果。
5. 应报告每位设计人员**所花费的时间。**此外，还应报告每个工作阶段所花费的时间，以便更深入地了解 HLS 和 RTL 版本中哪些部分最耗时。
6. 应报告输入代码的行数，以显示应用程序的规模和复杂程度。
7. 除了基本的 QoR 结果外，还应报告每个设计时间的性能，以显示 HLS 和 RTL 流程在生产率方面的差异。

6. Closing the Quality Gap

在任何特定应用中，HLS 和 RTL 方法的 QoR 通常仍然存在差距，通常是 RTL 更胜一筹。已有大量文献认识到了这一差距，并提出了缩小差距的方法。在本节中，我们将对这些文献进行梳理，以便为 HLS 研究人员和开发人员提供参考。

A. Research Directions for Tool Developers

一些人提出的对未来HLS工具还可能的优化方向：

[8]：

• 资源共享和调度是 HLS 技术中的两个主要特征，而目前的 HLS 工具仍在努力解决这两个问题.
• HLS 工具混淆了源代码和生成硬件之间的关系，这反过来又使其难以识别代码中的次优部分。
• 呼吁业界就基于 C 语言的 HLS 标准输入语言达成一致。这将为工具用户和工具本身解释源代码提供一种明确的方式。

[57]：

• 作者建议对循环流水线和开卷进行自动权衡分析，以提高 DSE 的速度。
• 要求支持 BRAM 端口复制指令，提高数据流转换的鲁棒性，并支持二维访问模式的流式计算。
• 建议工具应检测独立循环和函数之间的内存级别依赖性，并自动重新安排内存访问顺序，以实现分区、流式和更好的流水线。

[5]：

• HLS 工具应向设计人员隐藏外部存储器传输。
• 指出从顺序 C/C++ 规范中获取任务级并行性的困难，为此作者建议开发一种适当的设备中立编程模型。

[32]：

• HLS 工具应自动对动态数据结构进行类似的优化。

B. Improvements to the HLS Flow

由于研究文章的作者通常无法获得商业 HLS 工具的源代码，因此大多数改进 HLS 结果的论文都是通过在设计流程中引入新的优化步骤来实现的。本节将评述属于这一类的一些有前途的成果。

[58]：

• 使用并行模式模板，根据目标设备的特性来扩展模块的实现，这超出了 HLS 工具的能力。与标准 HLS 工具流程相比，作者的研究显示速度提高了 2.8 倍。

[59]：

• 采用了一种基于模板的方法，即使用针对硬件优化的通用计算模式的可组合和可参数化模板来提高性能。为方便用户使用，HLS 工具中可以包含这类模板。

[60]：

• 讨论了大规模并行算法中的内存访问瓶颈问题。作者提出了一种算法，可在不同流水线阶段调度内存访问，减少同时访问的压力。他们的方法将流水线性能平均提高了 43%，内存库使用率降低了 55%。

[61] ：

• 讨论了另一种减少内存访问开销的方法。该论文提出了一种新颖的算法，在一定的面积限制内将数组有选择地标量化到片上寄存器。结果表明性能有了显著提高。

[62]：

• 识别从顺序基本操作合并而来的自定义操作。这就降低了合成算法数据流图的复杂度，进而减少了合成运行时间，提高了 QoR。

[63]:

• 研究了寄存器分配的效果。该论文表明，在大多数情况下，采用简单的资源分配策略（即每个变量一个寄存器，不共享寄存器）可获得最佳 QoR 结果。

[64]:

• 研究了不同编译器选项对 QoR 的影响，并开发了一种方法，只自动选择那些能提高 QoR 的选项，与通常的 -O3 优化级别相比，平均提高了 16% 的性能。

[65]：

• 通过合并不同的行为描述，而不是分别对每个行为描述执行 HLS，可以显著节省面积。这是由于当 HLS 工具可以在描述之间共享功能单元时，可以更好地共享 FPGA 上的功能单元资源。本文提出了一种在给定延迟约束条件下寻找最佳合并的算法。

C. Design Space Exploration

探索最佳设置的设计空间应该是自动化的，但目前主流的 HLS 工具无法帮助用户完成 DSE。另一方面，也有一些学术论文对 HLS 中的 DSE 自动化进行了研究。

[66]：

• 介绍了一种直接的自动化迭代 DSE 方法。该方法的重点是减少面积，与非引导 HLS 流程相比，其 QoR 提高了 50%。

[67]：

• 介绍了一种基于自适应窗口法的更复杂的 DSE 算法。该算法在运行时间和找到最佳 QoR 之间取得了良好的平衡。

[68]：

• 提出一种专门针对具有嵌套循环的应用的类似方法。与穷举 DSE 相比，在取得类似结果的同时，速度提高了 235 倍。

[69]：

• 将基于模型的顺序优化方法应用于 DSE 问题。该论文表明，该方法可以在合理的时间内从数以万计的可能设计空间中找到全局最优点。

[70]：

• 在 HLS 之前增加了一个轻量级预处理步骤，对目标算法进行动态依赖性分析。这种方法可以揭示资源共享的机会，当这些机会作为约束条件提供给 HLS 工具时，就能获得更好的 QoR。

[71]：

• 讨论了寻找最佳循环解卷因子这一具体而重要的问题。作者开发了一种算法，用于在给定面积约束条件下找到最优解卷因子，并证明与其他可能的解决方案相比，该算法能提供最佳性能。

D. Verification

[72]：

• 广泛讨论了 HLS 的验证问题。作者指出，逻辑冗余会降低测试覆盖率，是 HLS 的一个主要问题。逻辑冗余可能存在于源规范中，但也可能由 HLS 工具在生成 RTL 时引入。因此，HLS 工具的开发人员应努力消除产生逻辑冗余的倾向。此外，在验证过程中，还可以使用形式化工具来识别冗余。本文还提倡将源代码检查作为改进 HLS 的一种方法。它不仅可以用来检查错误源，还可以通过证明 FIFO 大小等属性来帮助优化设计。

[5]：

• 提出了三个值得注意的点，使大部分调试发生在片上验证的行为输入语言层面：

  • 以较小的开销添加调试逻辑的能力；
  • 观察 FIFO 等关键缓冲器的能力；
  • 使用源代码中的断点观察硬件块内部状态的能力。

  由于机器生成的 RTL 代码，这些重要的调试功能无法在执行 HLS 后的 RTL 层上实现。

SUMMARY of Reviewed Papers