从FPGA到ASIC，异曲同工还是南辕北辙？

　　在这个场景下，每次MAC需要3个周期才能完成，复杂的流水线实现会给带来很多debug的空间。然而在ASIC实现中，8-bit MAC仅仅需要一个周期，跑到500MHz是分分钟的事情。由此，如果照搬FGPA的RTL到ASIC，那将带来许多平白无故的性能损失。该问题可能在时下越来越流行的低精度神经网络中越来越显著，比如在ISSCC 2018中韩国KAIST提出的新形复用MAC，在乘加内部做了新逻辑，完全超出了FPGA的mapping范围，但是其在功耗性能上的优势显著。
　　同样的问题还发生在片上RAM的使用。笔者认为，CNN专用处理器和经典SIMD计算/矩阵乘加速器 最大的差别，就是在于利用CNN的数据复用实现多样化的data flow上。而实现各种data flow的切实需求就在于有一个不大不小的scratchpad用于实现存储partial sum。目前主流的设计，每个MAC对应scratchpad大小在0.5kb-2kb左右。而FPGA片上macro IP（RAMB18E1）提供的BRAM/FIFO 的单位尺寸为18kb，显著地大于scratchpad的需求。
　　于是这个scratchpad在FPGA上的实现又陷于两难，直接综合将消耗大量的LUT中DFF的资源，如果用片上macro，又有一定程度的浪费，并且挤压了用于存储feature/weight的空间。由于这个scratchpad大小的尴尬处境，很多FPGA的DNN实现专注在矩阵乘法（Matrix product）的实现上，而放弃了在CNN/DNN中复杂data flow的支持。同样地，这个问题在以RAM compiler为基础的ASIC实现上毫无问题，毕竟ASIC设计中可以自由配置scratchpad的大小。
　　综上所述，FPGA和 ASIC在面向AI的专用设计中，虽然表面都是写RTL，但是在具体架构和思想上已经有了较大的差异。FPGA设计的最优解是最大化底层marco IP的拼积木设计，而ASIC却完全没有这样的限制，以放飞自我的方式寻找可能。由此，照搬FPGA而来的ASIC很有可能在某种程度上受这些限制的影响，也无法达到存在的ASIC最优解。这或许也是为什么深鉴在FPGA原型开发完成之后，还付出了大量努力才能完成真正ASIC设计的原因。
　　FPGA原型验证：
　　食之无味，弃之可惜？
　　传统意义上，FPGA出现的一个重要因素是为了给ASIC做原型验证（Prototyping）的。不可否认，原型验证仍然是FPGA的一个重大市场。

　　在AI应用中，除了对RTL code的功能验证和高速仿真外，FPGA Prototyping对于产品的更重要优势在于，更早地让嵌入式软件设计（Embedded Software Development）进入整体设计流程。软件领域的bug和灵活度的数量级往往都远高于硬件，如果等ASIC流片完了再对软件和系统接口着手，那也是白白浪费时间。原型验证的一大优势就是尽早地从系统和集成的角度，以硬件原型着手进行软件与嵌入式的开发。而于此同时后端以及流片的ASIC研发时间可以同步进行。
　　但和RTL simulation相比，Prototype的debug性差也是路人皆知的。常见的FPGA Prototype的debug方法是人为的在RTL中设置观测点（probe），调用片上BRAM存储，然后用类似JTAG的串口方式读取存储信号，再现波形。显然地，这种观测方法方法是在和有实际功用的RTL竞争片上BRAM资源，特别是在存储深度大，位宽宽的情况下。更严重的问题是如果发生了新一轮规模性的修改probe，而导致的重新综合与实现可能会耗去大量时间，可能还不如simulation的效率高。目前主流的FPGA的debug方案基本都是如上思路，如下图中的ChipScope+ILA模式。

　　不仅如此，FPGA prototyping在复杂时钟设计中的表现也令人堪忧。对于FPGA的初学者，门控时钟（clock gating，CG）几乎是完全不推荐的。而作为最主流的ASIC降功耗手段，CG几乎存在AI芯片的每一角落，特别是在具有稀疏性的网络中，门控时钟是最简单易行的降低功耗的做法。FPGA对这一特点的弱支持将导致原型验证可能存在不完整性问题。除此之外，多时钟域的问题在FPGA的原型验证也是一个问题，由于FPGA片上的PLL资源受限，在原型设计中也将收到诸多限制。
　　上述种种原因的情况下，FPGA作为AI芯片的原型验证重要平台，虽然仍是不少产品的重要选项，但是目前的受到的挑战令他越来越后继乏力。
　　Hardware Emulator，
　　领域专用的FPGA
　　随着集成电路EDA工具的发展，一个兼具良好debug性能，又可接近原型功能提供软件开发的便利的新型SoC系统开发工具正在崛起——hardware emulator（硬件模拟器）。可以说它兼具了simulation和prototype的优点，又在很大程度上弥补了缺点。目前主流的EDA工具开发商均提供emulator平台，并且期望在不远的将来，实现以emulator为中心的SoC开发流程。Synopsys 家的Zebu，Cadence家的Palladium和Mentor家的Veloce。其中Zebu就是以Xilinx的高端FPGA为基本元件搭建的。
　　从技术角度上，FPGA emulation 和 prototype的差别在于——emulator的RTL mapping是将原本的RTL分解映射（partition）到多块FPGA上，每块FPGA本身还集成了用于debug的观测硬件部分的代码。在Partition同时，设计EDA软件还关注模块间的通信行为，通过FPGA集成的高速传输（high speed link）和路由（router）特性完成实现SoC partition，避免了在单一FPGA中硬件资源受限制的问题。

　　下图从性能的角度比较了以FPGA为核心的原型验证平台与模拟器平台的上的区别。可以发现，emulator虽然在速度上并不具有优势，但是，其在内部数据的可观测性，以及由此带来的debug的可实现性能，均具有明显的优势。可以说，基于FPGA的模拟器正在并非对AISC 设计原代码的直接映射，反之是在源代码基础上通过Partition， Interconnection，Probe-serialization等一系列RTL的再生成后，产生的新RTL的映射。拿时髦的话来讲，emulator是领域专用的FPGA Prototyping。

　　当然，FPGA emulator有一个明显的劣势，那就是贵！对于刚过门槛的AI 硬件startup们，购买一台emulator是真的在流血。但即使如此，随着AI ASIC对于系统和应用的要求越来越高，未来基于FPGA的Emulator取代基于FPGA的Prototyping是否将成为一种潮流？让我们拭目以待。
　　FPGA AI：
　　是否需要走ASIC的老路？
　　如前所述，FPGA设计很难直接照搬到ASIC。事实上，FPGA上的AI应用是否真的要走传统ASIC的老路，即“发现需求——定义产品规格——上量大规模出货——以年为时间单位更新换代”？我们认为，FPGA的可重配置特点让它完全没有必要走这条路，而是可以走更接近于软件开发模式的道路。
　　一个例子就是最近流行的云端FPGA instance（AWS，阿里云等），用户可以根据其自身的需求在云端FPGA instance上烧入相应的bit-stream，从而让FPGA能成为针对你应用的专用加速器。另一个云FPGA的好处在于潜在地统一了FPGA的选型，令开源工作的移植减少了很多不必要的配置bug。著名的NVDLA的FPGA版本就以支持AWS的FPGA平台为主要方案。
　　至此，FPGA AI这样一来设计迭代速度（尤其是配合了Chisel，HLS等敏捷开发流程之后）可以远远快于传统ASIC流程，同时硬件的能效比则远高于传统的CPU／GPU。这一招在异构计算得到越来越多重视的今天可谓是迎合了潮流。这也是为什么我们看到微软，亚马逊都纷纷在云端数据中心部署FPGA，而Intel则也在往高端CPU里加入Altera FPGA。未来，这种新的模式可望成为FPGA市场的一个新成长点，值得我们关注。
　　最后做个小总结，
　　（1）对于AI硬件的实现而言，FPGA和ASIC的 优化路径有很大区别，从FPGA到ASIC的直接移植并不是一种高效的做法。
　　（2）强调一下这里并不是说基于FPGA的AI实现就没有未来，（相反我觉得还潜力无限），本文只是对于从FPGA到ASIC的直接移植提出了一点小想法。我们预计FPGA将会配合敏捷设计拥有自己的新生态。
　　（3）FPGA对SoC设计流程的影响正在从原型验证往硬件模拟的角度发展，你的产品有没有掉队呢？



原作者：ChipMonk 矽说