日志

阻碍高层次综合设计方法学(HLS)推广的因素这么多，该从何处突破？ ...

已有 1348 次阅读| 2020-1-15 20:04 |个人分类:验证系统思想|系统分类:芯片设计

从软件代码自动生成优化的硬件电路的能力是系统级设计自动化的主要原则之一，其并未完全实现。现在的问题是，这种情况是否会发生，是否仅仅是拥有正确技术或动力就能使其成为可能。虽然高层次综合（HLS）确实来源于这项工作，且被证明是非常有价值的，但是其输入并不是软件语言。相反，它是对硬件的更抽象的描述。大多数HLS工具可以使用C语言、SystemC或者C++作为输入语言。

Codasip的营销副总裁Chris Jones表示，关于C综合的普遍抱怨一直存在，且仍然是它不是“真正的”C或者C++。以至于该语言最后会具有可测的自定义语法，当然，用户也可以用Verilog编写。
当谈及由C/C++进行综合时，该术语有两种解释。Cadence产品管理总监Dave Pursley表示，从技术上来说，C++是一种“语言”，但从C/C++语言生成硬件电路模型来看，它也意味着算法的抽象级别。Dave Pursley还说：“虽然HLS将综合您使用的算法，但是为了获得更好的硬件电路设计，您需要从硬件的角度编写算法。”
这意味着原始的C代码经常会被修改。OneSpin Solutions的营销主管Bob van Blommestein表示，算法通常是用C/C++编写的，但是缺少了硬件实现所必需的SystemC的详细信息。即使SystemC模型对于高层次综合来说也常常过于抽象了，在将其转换为硬件电路模型之前必须对其进行完善。这种模型，特别是由软件团队编写的模型，很少反映硬件电路的重要方面，例如流水线、有限的内部存储和有界的内存带宽等。
也有其他人报告了类似的困难，Silexica产品副总裁Jordon Inkeles表示，使用HLS将软件代码综合成实际的硬件电路时，存在几个基本挑战，其一是代码必须由HLS引擎合成，也就是说，必须将代码编写或重构为硬件可综合的格式，其对习惯于使用标准C/C++编写的软件工程师而言非常重要。其二，HLS编码的可综合性准则很重要，工程师必须熟悉这些涵盖数百页文档的准则。
Inkeles说，一旦代码可综合，还需要一定程度的底层硬件意识。他还补充表示，当将某些东西放入硬件电路设计时，考虑资源的使用就很重要了。例如，当编写要在处理器上运行的软件时，工程师可能对所有数据类型仅使用浮点数，而不会产生重大损失，但是在硬件中实现时，这会导致额外消耗宝贵的硬件资源，可能会增加成本，也可能降低算法的性能。
那么，从软件语言进行综合是一种幻想吗？Arm研究架构主任兼研究员Stuart Biles表示，从C++、SystemC、Matlab或者其他行为定义出发的高层次综合（HLS）在过去十年中已经走了很长一段路。HLS是许多应用程序的理想选择，尤其是在无线电、音频或图像处理等领域中可能会发现的数据处理通道。当与FPGA结合使用时，它可以通过部署前在开发系统中观察到的性能反馈来促进快速原型设计、验证和优化设计周期等。
高层次综合也已在其他应用领域得到认可。Jones表示，其他高级描述语言正在被使用并且获得了市场的认可，从像Synopsys的NML或Cadence Tensilica的TIE等成熟的语言，到Chisel和Codasip自己的CodAL等新语言，这些语言最好应被定义为“处理器描述语言”，并以多种不同的方式被使用，但其主要的使用是自定义已建立体系结构的指令集或从头开始设计处理器。
市场压力也正在增加。CacheQ首席执行官Clay Johnson表示，摩尔定律的衰退意味着处理器大体上不会再像过去的30到40年一样继续提高性能。还需要一些其他的技术，如机器学习和FPGA等领域的GPU、定制设备等。众所周知，FPGA确实可以加速事情，但是其开发环境从传统上到今天一直都集中在硬件开发人员而不是软件开发人员身上。
许多开发团队的组成也正在发生变化。Achronix副总裁兼首席技术专家Raymond Nijssen说：“有一位客户告诉我，他们基本上没有人可以写RTL，但近30000的人可以写C/C++，在他们中间有些人说他们比工具能做得更好，但这些人就像恐龙一样濒临灭绝。他们被那些想按一下按钮而又不在乎解决方案是否完美的人们所取代。对他们来说重要的是，他们很快就能得到结果。周转时间也开始越来越推动了这一点。因此，您要为效率付出代价，让工具能更快地为您提供结果。”
CacheQ的Johnson表示同意这一观点。“如果我是FPGA的核心人物，我将能够选择一项功能并对其进行设计，从而获得更小的面积和更高的性能（也许是这样的）。如果您要查看大型FPGA，我将规定硬件人员如果不能充分地理解所有的算法细节将不足以在详细级别实现这些。”
过去，许多协处理器的解决方案一直受到通信成本的困扰。Nijssen指出，加速器之间没有良好的通信协议，其延迟时间不足以证明将工作负载从一个处理元素转移到另一个处理元素是合理的。如果需要花费毫秒将某个矩阵从一个地方移到另一个地方，那么由于移动物体的时间和成本，CPU将能够以更少的精力同时完成任务。
Mentor，a Siemens Business的HLS平台规划主管Russell Klein表示，嵌入式FPGA在这一领域将变得很有趣。如果FPGA是一个单独的器件，则从芯片外移植到FPGA可能会使从软件代码到硬件电路的实现的许多好处都无效，但如果将FPGA保留在SoC上，则将减轻这些问题。

寻找适用对象
并非所有软件都适合映射到硬件。Arm的Biles表示，尽管目前的结果并不是最佳的，但可以映射出与高级规范一样复杂的处理器。诸如转发和控制流之类的概念映射得并不尽如人意。而对于数据处理这个控制决策较少的领域，反而更容易有效地进行映射。对于设计人员来说，没有大量配置参数或多种操作模式的应用程序更容易满足，因此它们已经综合了有效的实现方式，并且没有重复常见的功能。性能来源于采取串行过程和利用并发性。Johnson表示，获得性能的方法是加速循环。如果您查看C代码，则复杂算法的大部分时间都花在循环中。加速循环的方法是使循环完全流水线化。在处理器中，如果我有一个循环，并且该循环是n次迭代，需要C个周期才能完成，那么处理器所需的时间大约为(n x C)/时钟速率。如果完全流水循环，则时间量为(n + C)/时钟速率。
这是HLS增值的地方之一。Mentor的Klein表示，高层次综合工具在发现和引入并发方面做得很好。在由于算法描述的性能而无法提取并发的情况下，它将为开发人员识别依赖关系，使他们能够手动修改代码以增加并发性。
因为硬件和软件工程师的观点和经验水平是不同的，困难也就从这里开始。Cadence的Pursley表示，要考虑一个复杂的多级图像滤波器时，在纯软件中的每一个滤波阶段，C++可能有多种功能将通过复制帧或将指针传递到帧进行通信。但是由于它将由优化的硬件执行，这不是算法。通常，硬件将尝试最小化存储，并尽可能避免昂贵的帧缓冲存储器。相反，为了获得良好的QoR，如果它是一个2D滤波器，则该硬件滤波器可能会通过线路缓冲器绕过像素。
Silexica的Inkeles表示，从硬件实现中获得最佳性能的技巧之一就是优化应用程序中的并行性。但这需要对算法有深入的了解，以指导HLS工具如何实现并行性。通过使用一种工具来检测设计中的隐式并行性并重构代码以对其进行转换，当在硬件中实现时，开发人员可以最大程度地提高算法的性能。
数据存储和移动至关重要。Johnson说，“我可以进行大量的计算，但是我必须具有支持该计算的数据的能力。这意味着，如果我没有足够的内存带宽或足够的内存访问权限，那么我将会有一个循环，该循环可以非常高效和快速地运行。但是，如果我因数据访问而陷入僵局，那么我将无法提供这种性能。”
许多算法都受到内存访问性能的限制。Klein补充表示，通常不是计算时间成为瓶颈，而是将数据转移到计算单元上需要花费大量时间和精力。同样，这是设计者而不是编译器的责任。
但是对于软件工程师来说，还有更大的障碍和问题。Klein说：“高层次综合没有全局可见性。尽管它可以很好地使用所使用的模块，但是它不能考虑其他模块（例如不使用高层次综合功能的模块或软件）中的活动。”
Pursley提出了更具体的说法。“HLS本质上是一种不同类型的编译器，因此，根据经验，必须在编译时完全解析C++。它明确规定，在块之间的时序同步方面没有隐藏的假设。例如，因为最终您需要在实际的硅片上实现某种物理尺寸的存储器，所以您不能拥有无限制的malloc()函数。”
这种限制不适用于软件工程师。Johnson说：“如果我是软件开发人员，我想在变量上指明malloc()函数，我想要分配内存，我想要指向该数据，然后并希望数据返回。使用HLS，我必须根据我使用HLS工具所做的事情来构建存储器结构。这是一件极其复杂和困难的事情，这就是为什么开发某个东西通常需要9或12个月的原因。对于软件工程师来说，这是一个巨大的负担，他们无法建立存储器结构。”

设计解决方案在这里，每个开发团队的解决方案可能会有所不同。Pursley说：“作为硬件设计工程师，您可能希望显式地建模诸如位宽和进程级并发之类的东西。在这些应用中，您的C++模型应使用IEEE 1666标准C++类库，SystemC。”硬件工程师的目标是尽可能实现最有效的执行。Johnson表示，软件工程师想要采用标准的C代码，并能够将x86和FPGA结合起来作为加速器。他们想要以一种他们熟悉的方式来做到这一点，而不是要拥有硬件背景的人。
考虑到以FPGA为目标可能会打破这种平衡。Biles表示，如果最终产品的目标是FPGA而不是ASIC，则可能需要一种高级的编译方法，这不仅仅适用于快速原型模型。因为它可以根据观察到的应用程序行为快速增强算法，所以可以带来更好的实际性能。
Silexica使软件工程师能够将其C/C++代码转换为硬件电路的方法是，在执行HLS之前帮助优化其应用程序代码。Inkeles表示，通过在HLS阶段之前执行并组合静态、动态和语义代码分析，我们可以指导软件工程师解决不熟悉的硬件代码，本质上，可以指导软件工程师合成其代码并在顺序代码中识别并行性。随后，该工具会自动将编译指示/指令插入代码中，以指导HLS编译器。在HLS设计流程中添加代码分析工具可以大大减少软件工程师在尝试将其软件语言转换为硬件电路时所面临的障碍。
CacheQ正在尝试一种解决方案，该解决方案可能使软件工程师可以使用此技术。Johnson解释说：“我们生成了一个虚拟机，这是一堆指令，其中的指令就是您想像成的微处理器指令集（条件、布尔函数、算术），并且我们生成了这些指令的可连接虚拟机，它们的连接方式是数据如何流经系统。通过这样做，它使我们可以运行性能仿真以确定其速度。我们可以在处理器和FPGA上进行分析，这种表现使我们能够自动且完整地进行流水线循环。”
关键是查看代码并找到需要加速的主循环，然后确定该循环的补充功能。Johnson说：“我的printf()函数将在处理器中完成，而不是在FPGA中。仅具有在FPGA中编写代码并生成某些东西的能力是不够的，您必须具有对此进行性能模拟、进行某种性能分析的能力，以便可以识别代码中的热点。这就是FPGA的内容。所有指令均以某种方式运行，以便在数据可用时触发它们。如果所有的输入都不可用，则指令将等待。这使我们可以执行一些我们不完全知道访问内存的返回时间的事情。而且，能够从同步的角度确定何时按正确的顺序进行操作，这是虚拟机可以理解并能处理的。

验证软件世界和硬件世界的另一个不同体现是在验证中。软件工程师从不考虑验证编辑器的输出，但这恰恰是硬件工程师的标准习惯。Breker Verification Systems的副总裁兼CMO表示，常规综合可以依赖正式的等效性检查工具来分析静态寄存器间的设计逻辑。对于非定时逻辑，这要困难得多，可以使用有限数量的状态转换进行属性检查来解决简单的综合问题。对于严格的设计，仿真也是必须的。创建一个模仿DSP功能的基础测试平台可以为非定时到定时的逻辑综合提供一种严格的解决方案，这也是便携激励（Portable Stimulus）测试组综合工具的另一应用。
形式验证发挥着重要作用。OneSpin的van Blommestein补充表示，在C++/SystemC模型和后HLS的RTL代码之间有共享SystemVerilog断言。而且，C++/SystemC的静态分析工具与SystemVerilog的RTL可用的工具相似。这些可能检测到过度的数据长度、竞争条件及初始化错误等危害HLS的问题。尽管设计过程没有工程师们所希望的那样自动化，但自动化验证依然很关键。
这些问题对于以FPGA为目标的软件可能并不那么重要，因为如果发现问题，工程师们可以快速应用更新。

足够好的实现尽管有些人将其视为政治辩论，但这实际上取决于性能和生产率。Pursley提出他时常有这样的疑问，HLS能把软件代码综合成硬件电路吗？答案是不行或者更精确地说，不会综合成用户需要的硬件电路。
Klein将其数据化，假设用户可以执行“不好”的实现并将功能移至硬件，则可使该功能的运行速度提高100倍。你也许会发现，将数据与加速器连接和移动的开销会抵消大部分收益，因此在系统级，用户的速度只会提高10倍。但是创建一个“出色”的实现，其可以与手工RTL相提并论，它比不良的实现快10倍，比软件快1000倍。它仍然具有与不良实现相同的开销，因此，如果进行数学计算，不良实现和出色实现之间在系统级别上的差异可能小于1%。
但是软件团队有不同的看法，Biles表示想要获得一个操作时间，且该操作时间将高级别定义的部分工作量部署到最合适的执行资源（基于功能、性能和可用性），同时满足开发人员所提供的高级约束。该理想行为将通过软件和硬件的功能组合来实现，并且具有在需要时对其进行优化和重新定位的能力。
Johnson表示，把这种技术掌握在软件工程师手中将会大大扩展潜在的市场。因为人们编写软件的方式，所以他提出如何创建支持我们在谈论的各种性能的疑问。他说：“如果您无法做到这一点，那么您就无法扩展并说我支持非硬件的用户社区。软件人员不会进行大量的数据流分析，以准确地弄清数据流向何处，如何将其加载到内存中，以确保在我进行读取时就存在该数据，因为如果不是这样，我就会失败，而不是软件人员如何编写代码来分配内存，使我得到一个指针，然后访问该指针，并在某个时间点显示出来。作为一个软件专家我并不知道内存架构如何支持这一点。”

总结软件和硬件工程师处在不同的领域，并且对工具常常有着不同的目标。对硬件工程师而言，效率仍然是其驱动因素，而对软件工程师来说，生产力是其目标。工具供应商正在努力寻求满足两者要求的平衡。Klein表示，对于多数应用程序来说，即使是不良的硬件也比出色的软件要好得多，很多设计者都低估了软件的真正速度以及处理器（尤其是大型处理器）的低效性，想要超越软件和处理器的性能确实很容易做到。