如何看待赛灵思Xilinx收购Falcon Computing，以及Falcon主营业务的前景？ 第1页

丛老师是清北和硅谷华人半导体圈的明灯了，HLS异常艰难的搞了20年+，整体面向通用电路的好像没人做出来，都是局部场景商用，丛老师门派就是独道于此，前后也卖过几家公司了，跟AWS/Ali/HW/INTC/XLNX等都有合作。如今这家Falcon Computing才运营4年，Baidu和INTC早期都投过了。

记得最初看到Falcon的形态是数据中心用来加速Gene/RNA-seq算法的（HPC Bioscience任务经常处理的那种GATK应用）包括标准流程从organic sample--sequencing--各种reads到转录本--到Falcon加速的Genomics Pipeline(FPGA)--variants calling输出。但如今4年后的成熟产品栈还可以加速金融（期权定价模型和风控等）以及更多专用的ML场景（云端FPGA可随时重构-可换资源-可换ML算法）。

HLS的艰深在于高级语言映射到门电路，用来做专用ASIC和云端FPGA软核NPU可以，做通用处理器几乎不可能操作，冗余大到不可接受，跟RISC精神刚好背道而驰：）。硬件逻辑演进中为了支持某些特定算法或指令构造，可以电路实现，但随之的指令系统和访存逻辑等等也会发生变化，就要考虑上层抽象怎样表达、怎样方便码农的应用编程；同时上层程序中获得的数据输入和类型，传参到一堆算子之后还要继续把这个程序/算法向下数学化简和逻辑综合，这个通道上下无碍后，才会把现成的化简和逻辑写成各种Mathlib和例程，一直化简到电路实现的过程…，期间还要考虑到电路逻辑门的构造形式和状态/时钟/位宽等因素，这就是各层编译器逐级封装和解释的路径，最终固化到电路的最佳过程就是RTL/IPcore了。—— 那么到了硬件程序员的层次，挑战就是把HDL手调硬逻辑的难度降下来，且过程中都是有面积和功耗代价的，这也是为什么必须有仿真工具的原因。而丛老师的Merlin硬件编译器就是把C/C++/OpenCL等自动编译成RTL/二进制码，那么对于某些特定应用，仅需程序员的软件技能就足够了：）【同时缅怀一下老RTL工程师作为人肉综合器的岁月】

比如微软的Catapult项目（支持内部Bing搜索等应用）或是Azure云端的Brainwave项目，就是把训练好的DNN模型转成数据流图表示，然后根据单块FPGA的片上资源情况，对流图进行拆分并映射到FPGA的软核NPU上。这个过程就需要直接用HLS对DNN综合。AWS也有F1这样的实例，目前似乎仅支持Caffe而不支持其它DNN框架。总之相比GPU集群，FPGA集群对DNN（比如针对CNN/LSTM的低精度MAC乘加）做硬件加速的性能优化空间大/算法迭代灵活/片上资源多…

---------------------------------------

如下引据了老石谈芯的总结，其实微软和AWS的FPGA-as-a-Service类似，使用FPGA加速计算的目的和意义有以下几点：

• 将FPGA作为标准的AWS计算实例，提供给数以百万的AWS开发人员和终端客户。
• 通过提供基于云端的标准化FPGA开发工具，简化整个FPGA的开发流程。
• 通过使用统一定义的FPGA逻辑接口，抽象FPGA的物理接口，从而使得开发者专注于自己的算法设计和实现。
• 为各种FPGA设计提供一个统一的应用市场和交易平台，为所有AWS用户提供更多的选择和更加方便的使用。

目前，很多FPGA初创公司都在AWS应用市场发布了自己的AFI镜像（可以直接烧录FPGA的比特流配置文件），比如国内深鉴的语音识别引擎，英国Maxeler公司的金融计算加速应用，Falcon Computing的基因检测加速引擎，以及加拿大LegUp公司的网络功能加速应用等。此外，国内的很多云服务提供商也开始积极布局公有云的FPGA服务。例如，阿里云至今发布了三款基于FPGA的云计算加速实例，其中2018年发布的FPGA计算实例F3搭载了Xilinx Virtex UltraScale+ FPGA器件，而之前发布的F1则使用了英特尔的FPGA器件和开发套件。腾讯云也推出了基于Xilinx Kintex UltraScale FPGA的云服务，并将今后推出基于英特尔FPGA的计算实例。华为云也有基于Xilinx 器件的FPGA加速云服务器正推向市场。

------------------------------------------

针对几点线下提问的释疑：

• 关于HLS编译效率的疑问：虽然HLS技术可以大幅降低HDL手调硬逻辑的难度。但在当下，整体面向通用电路的没人做出来，都是局部/领域性的场景商用；过去数年各方都努力过通用场景的编译，但每当硬件升级、体系结构升级、高级语言版本更新或某个关键lib更新等等，当前HLS开发就要失效了，而再次更新它所花费的时间/成本甚至都超过了软硬件技术演进的节奏（以及早期HLS还被质疑浪费了太多片上资源和面积，电路也没法最优）。但在领域性场景的极致应用中，HLS的受众甚至不是RTL工程师，而是软件或算法工程师，虽然前者的优势在于对底层硬件资源足够了解，能够指导不成熟的HLS工具生成更好的HDL代码，但后者的优势是对于应用类型/workload类型/算法的敏感度，可以写出更好的并发机制的函数式语言，并方便这种软件程序导入到硬件并行平台上，也能更准确的判断对错和业务适配性。—— 然而当下的实现是RTL+HLS结合更好，就像Azure/AWS的F1实例那样，用RTL做控制电路，用HLS纯粹做通讯流处理和数据流ML计算；因此，受限于领域性任务的编译准确性和效率，HLS更适合纯算法，同时需要加以控制约束才能取得很好效果；
• 最后回复一个线下提问，关于HLS与二进制指令翻译的比较：这不同于Rosetta那种BT输出的还是指令（要解析以后走过已经固化的门电路），HLS是为C++启动的每条指令建立一条RTL路径并固化到电路实现上（犹记得深鉴以前的库是跟nn descriptive对应的RTL）。

BTW：如同Intel专家Stephen所说的，HLS一直以来是十分吸引战投的资产：）