作者：Steve Leibson, 赛灵思战略营销与业务规划总监
我上篇博文“我们能相信HLS吗？Brian Bailey想知道，也许你也想知道”，在LinkedIn网站各种FPGA相关的群组中引发了非比寻常的关注和讨论。
这是LinkedIn网站SOC讨论区中Joel Jamais的回复：
“事实上，我去年曾经被借调了几个月，去参加一个HLS项目，这个项目有两家有竞争关系的HLS CAD工具提供商，目标是一些已经完成RTL编码的IP模块。它们面临的挑战是优化面积、速度以及功耗。参赛选手是：
1: HLS工具提供商1号
2: HLS 工具提供商2号
3: 手工编写RTL代码
当时我在这个实验中的角色是一名工程顾问，工作仅限于设置和运行PLDRC（linting）、综合、静态时序分析、PTPX等工具，而RTL代码是由这两个HLS工具来输出，每天，这两个在幕后工作的HLS工具都会输出一次或者多次迭代的RTL代码。每一次迭代都会解决一些linting错误，或者是减小面积，或者是解决时序违例，或者是降低功耗。这个工作是不包括DFT的。经过两个月，初步结论是手工编写的RTL代码是最优的，然后是两个HLS工具其中的一个。随后，我被派到另外一个项目，因此失去了继续对HLS工具评头论足的机会。
考虑到在这个实验中我的角色的局限性， 我觉得，要想和有经验的RTL设计人员手工编写的代码去竞争，
HLS工具还有一些路要走，特别是那些控制逻辑多于数据通路逻辑的设计。换句话说，如果数据通路逻辑，比如一个DSP功能，已经是用C语言（或C++，或SystemC）实现编码的，那么完全有理由去使用这些HLS工具，因为，通过HLS工具转换得到的RTL代码，只需要再做一些RTL增量开发，去满足linting规则检查，实现面积、时序、功耗的优化，以及插入DFT。”
还是LinkedIn网站SOC讨论区，Brian Logsdon的回复：
“每一个正常的人在发布设计之前，都会使用HLS、GLS、STA、FEC以及PRA。要想交付的方案工作起来更有保障，唯一的方法就是使用上述所有的工具。”
这是LinkedIn网站上ASIC、FPGA和SoC工程师群组的ASIC讨论区，Doug Walby的答复：
“我正在构建一个验证用例去验证一个由HLS工具产生的设计。如果你喜欢象调试门级电路那样去调试RTL，那么HLS非常适合你。如果你更喜欢RTL代码有一个更实用的外表，并且喜欢在手工编写的RTL代码这样的抽象层次上进行调试，那么你很可能就会失望。如果你想要盲目相信自己的RTL代码没有缺陷，不经过RTL验证就发布，那么HLS可能会对你有帮助，这样可以避免出现另外一个人在使用RTL代码并行开发的同时，无法发现C代码中任何错误的情况。”
LinkedIn网站FPGA群组，Phil Duff的回复：
“我们在HLS上有着第一手的使用经验，我们正处于拓展产品的过程中，它是一个商业/工业的通信系统。然而，在使用HLS来获取高质量的结果时，确实是有一点不可思议的魔法在里面，我认为我们已经得到它了。对于熟练的使用人员来说，这类工具有许多有吸引力的地方，包括工作效率方面的优势。”
还是LinkedIn网站FPGA群组，Ed Henciak的回复：
“我确实喜欢我用HLS综合过的代码逻辑（相对比较简单的），这个夏天，我将要尝试一些更复杂的代码。
在使用HLS时，我卡在了一个地方，就是要象AXI总线主/从设备那样去表达事物。虽然我没有主动去寻找参考设计，但我并不觉得这有多简单。我可以轻而易举地使用HDL编写一个新的主/从控制器。。。用C语言来写看起来就相当笨拙。可悲的是，用HDL来写就意味着我必须对这个设计进行仿真，这样跟在我的PC机上直接运行可执行文件进行“仿真“相比，在效率上就会低一些。
我多了很多图像处理的工作。。。我总是和帧缓存以及PCIe逻辑打交道，通常情况下，这些逻辑都是基于AXI总线或者AXI-S总线接口。
在仿真图像处理逻辑时，需要在仿真环境中提供相当大的数据量来一起工作，这是非常折磨人的事情。HLS就可以允许有一些真实的、有趣味性的验证方法。
重复一下，我在HLS方面相对来说还是一个新手，所以，如果我的描述中漏掉了一些显而易见的事情，那么请原谅我吧。多年的FPGA HDL的设计经验会遮蔽一个人的视野 :-)。”
Sharad Sinha对Henciak的评论的回复：
“用C语言来编写象AXI这样的接口确实是非常困难的，因为C语言没有任何时序的概念。这也就是为什么在最新的Vivado-HLS（它的前身是AutoESL）版本中有一些选项，可以使用AXI等接口对C语言产生的RTL代码进行一层封装。我还没有对它进行测试，所以我不能评论它有多么好，可以试着去阅读这篇文章的第7页：（在Zynq-7000 All Programmable SoC中，使用Vivado HLS实现浮点矩阵乘法加速器）
同时，HLS工具是假定使用人员具备硬件设计基础知识的。这些工具有许多编译指示和指令，使用人员可以用来指引工具进行工作，但是，如果一个人不能理解这些指令怎么对硬件设计产生影响，那么他就无法使用这么多的指令。”
另一个评论来自于Phil Duff：
“有一些评论恰好反映了我最初的担忧，我们对事情如何实现缺乏必要的理解。作为一个非常有经验的HDL编码人员，在RTL层次上编写代码，HLS工具的权衡是很有意思的，下面是HLS的一些主要的卖点：
1）'C'的行为仿真非常快，尽管有些结构也会非常慢。在共享存储器（Zynq）中实现一个32MB定点精度阵列无疑是让人绝望的，但int类型是易于实现的，在硬件上，这仅仅是个入门设计。
2）一旦你掌握了AXI总线，那它几乎就是微不足道的。你会碰到一些带有用户自定义数据结构的数据流、同软件之间的接口（需要编写底层驱动）、共享存储器的DMA访问，等等。
3）RTL编码人员知道，“白板”的数据通道是非常容易实现的，有些棘手的是控制状态机，使它的所有功能都能正常工作。HLS能够编写状态机，可以为你节省大量的时间。只需要改变几行代码或者一些编译指示，架构就会发生非常大的变化，可以在资源、延迟以及吞吐率方面进行比较多的权衡。
4）RTL编码人员对可能的实现结果以及不同方法所产生的结果能有一个很好的理解。
5）能为Linux等编写底层驱动。
6）准备好IP模块，集成到IPI。
虽然如此，这里也还有一些困难，要想熟练掌握这个工具，能通过编译指示、代码布局、使用任意精度类型、接口数据结构等等来充分利用这个工具，我们需要进行专业化的培训。HLS需要有一个投入，才能给我们最好的回报，我想我们都不会停止学习。
我们能相信HLS吗？我们已经得到了我们开始想要得到的答案，并且感觉到我们正处于一个正确的位置上。当然，我们也做出了一些妥协，但这就是工程设计。最大的问题是工具的一个长期的演进，已经说过，我们在体系架构方面有丰富的知识，因此，如果有必要，我们可以使用一个不同的工具流程来重新实现架构。
原文链接：
http://forums.xilinx.com/t5/Xcell-Daily-Blog/Can-HLS-be-trusted-blog-gen...
© Copyright 2014 Xilinx Inc
如需转载，请注明出处
