注：以下讨论我在暑期讨论组读过的一篇文章，作者们来自微软，主要是从计算机架构上对一些新的尝试，刚刚被ISCA会议接收，是一篇新鲜出炉的文章。我觉得挺有意思，在此分享我的看法，希望抛砖引玉。如有错漏之处，望请指正。

文章: Putnam et al.  “A Reconfigurable Fabric for Accelerating Large-Scale Datacenter Services”,  ISCA 2014,  
链接：http://research.microsoft.com/pubs/212001/Catapult_ISCA_2014.pdf

这项研究主要用的是FPGA阵列来对 Bing 搜索进行加速。作者设计方案是：在每台服务器的PICe接口连接一个FPGA板。一个Rack有48台服务器，相应地，一个Rack需要48个FPGA。在逻辑上，这些FPGA间是直接互联的，但不用服务器的ethernet, 它们有自己的二级网络。48个FPGA组成一个6x8的二维的拓扑结构。每个FPGA都配置有一个8G的DDR3 RAM, 为什么需要RAM的理由在以下讨论。

为了尽量少地改变原有的服务器架构，作者们选择将FPGA连在每台服务器的PCIe上，服务器CPU与FPGA的通信先经过南桥，然后经过PCIe线。之所以不是用其他方法，例如北桥上开一个通道，直接与RAM相联，就是为了最小限度地保持原有架构，这样对服务器的生产也方便（作者还有一点没说，这样的设计也让实验做起来方便，因为他们不用专门去定制48台server, 在原来的上面改就好了）。

但这样的设计有两个缺点：a. FPGA和CPU间的数据传输速度会受到限制，PCIe 有带宽限制，一般PCIe 2.0 的峰值是5Gb/s, PCIe 3.0 是8Gb/s, 而FPGA间的互联网络速度都能达到 20Gb/s， 貌似PCIe 会成为瓶颈。但在bing 搜索的workload里影响不大，因为数据传输量并不大，从服务器传到到FPGA也就是一个个64Kb的文件，PCIe 也能满足需求； b. FPGA 所在的是IO空间（也就是在南桥southbridge上），作者们并不想让FPGA 直接通过DMA去访问内存，因为这样会导致与CPU和其他部件对 memory bus 的争夺, 而是在FPGA另加了一块8G内存，用来放FPGA的临时数据。

这种设计的前提是，问题已经被充分定义和分解好的，分解成一个个适合FPGA运行的任务，让它们可以pipelined。这在Bing搜索这种应用里是可行的，因为它已经明确定义好了一系列骤：feature extraction -> free-form expression -> compression -> scoring,  与Map-Reduce后的处理有点类似。本来这些步骤都是在单个处理器里的微型流水线(pipeline)里完成的，但是这条流水线分到了一个个FGPA里，变成了一条macro-pipeline. 之所以用macro-pipeline能加快速度，是因为这些任务的性质是属于 MISD (multiple instruction, single data) 类型，单个处理器里反复对一个相同的数据进行操作，也就只能用一条垂直的pipeline, 指令是序列化的，而用macro-pipeline就可以实现instruction -level parallelism，是水平方向的并行，效率自然大大提高。

文章标题说的 reconfigurability 其实不太准确，它实际的意思是，写好一些程序逻辑（在bing 搜索里，他们称之为model），放在每个FPGA的buffer里，然后实时地根据query的不同，把不同的model 载入每个FPGA里去。但是，FPGA 的底层运行程序还是事先写好的，所以微软雇了一堆精通FPGA的程序员，花了几个月把FPGA的程序调好，这也就是为何本文有24位作者的缘故。

然而，这种模式在实际产品中行得通吗？要FPGA 产商为每个人企业用户定制他们的程序逻辑，这恐怕不太现实，只能是企业自家来写这方面的程序。无论哪种方式，是对开发者和产品调试来说，要维护FPGA上的应用程序逻辑是一件麻烦事。例如，Bing搜索每更新一次搜索算法，在FPGA上面跑的models也要更新，这恐怕得费一番力气太行。

从效率上上说，在Bing搜索上的应用还算可观的，有95%的加速，意味着你只要新增一个FPGA阵列，就能达到新增48台服务器同样的加速效果，成本大大降低。问题在于这种方案的通用性，以及FPGA上程序的可维护性。