【摘 要】本文论述了FPGA系统设计中，利用FPGA内部DCM和IOB资源设计高速并行接口，相比于利用SERDES和LVDS设计的并行接口，大大降低了系统设计的难度。该种方式通过在高速数据采集系统设计中的测试和使用，验证了设计的有效性。
　　【关键词】FPGA；并行接口；DCM；IOB
　　任何系统中接口唯一的交互手段，接口设计对系统有直接影响。随着处理带宽的与日俱增，特别是FPGA高速并行接口设计要求越高，难度越大。本文结合高速数据采集系统设计需求，提出一种基于FPGA内部资源DCM和IOB的接口设计。 设计满足了高速率、高效率、高灵活性的特点。
　　2.时钟源同步设计
　　在系统设计中，通常采用数据与采样时钟同步进入FPGA的源同步设计方式。如果时钟与数据的相位保持不变，那么在FPGA内部将可以正确采样数据，但实际是时钟进入FPGA后经过了一系列路径后改变了原有相位关系，对采样造成危害。为了消除潜在危害，在设计中要保证数据与时钟的相位关系保持不变，即在FGPA中要用到DCM的内部反馈，其内部反馈原理如图1所示：
　　图1 DCM反馈原理图
　　在DCM中有一组延迟单元组成的可变延迟线，通过控制反馈MUX调整时钟延迟，从而达到调整A点与C点之间相位关系的目的。DCM有系统同步和时钟源同步两种反馈模式，系统同步反馈用于设置A点与C点之间的固定相位差；时钟源同步反馈用于调整A点与C点之间的相位，使其相位差为0。在本设计中用时钟源同步，使A点与C点同相位，从而保证C点与D点相位关系与原有A点与D点相位关系一致，即数据与时钟的相位关系不会因FPGA中的路径和逻辑而改变，保证了时钟对数据的精确采样。从图1可以看出A点
　　之前路径延时不能用反馈方式抵消，因此FPGA设计中要求时钟从专用全局时钟引脚GC输入，否则时钟不能上FPGA时钟树而使A点之前路径布线延迟大，造成原有数据与时钟之间相位关系改变而导致采样风险，同时也会使EDA工具报告错误。
　　因此接口设计中时钟处理注意两点：一是时钟要通过DCM做反馈；二是时钟从全局时钟引脚进FPGA。如果必须存在非全局时钟引脚时钟输入且不影响功能的前提下，可以通过以下约束：NET “clock_name” CLOCK_DEDICATED_ROUTE = FALSE，使EDA工具忽略报告错误。
　　数据同步分为两种情况：一是本身同步的数据进入FPGA后造成了不同步；二是数据本身不同步需要在FPGA内部同步处理。本文讨论第一种情况。通常在FPGA设计中如果对接口不做任何约束，让EDA工具进行自动布局布线，其布局布线后的电路和时序结果如图2所示：
　　图2 IOB约束前接口数据图
　　数据从IOB中的PAD进入FPGA后经过一段不确定布线到达第一级寄存器，不确定布线导致不确定的路径延时，从而使本身同步的并行数据进入FPGA后bit与bit之间相位偏移，使图2中时钟采样时序容限F变小。如果时钟还是以原有相位关系采样数据，可能造成数据采样的错误。为了解决这个问题，需要对接口数据做IOB约束。IOB约束语法为：INST “Instance_name” IOB = 　　图3 IOB约束后接口数据图
　　通过IOB约束后，EDA工具布局时用IOB中的寄存器替代原第一级寄存器，使PAD到第一级寄存器之间的距离相同，因而消除bit与bit之间相位偏移，保证了数据同步而提高了数据采样的时序容限F。因此在FPGA中IOB约束有两个好处：一是保证了数据同步；二是使用IOB内部寄存器，减少了对其它资源的占用。通过对接口IOB约束，然后在FPGA Editor中进行布局布线延迟分析，其结果如图4所示：
　　结果分析了并行数据中一位的变化。从结果看，在IOB约束前数据从PAD到第一级寄存器路径延时为1.326ns，而约束后延时为0ns，从而消除了路径延时对数据同步和采样的影响。
　　本文结合DCM与IOB的特点，提出FPGA并行接口设计：一是将接口并行数据设置IOB约束，保证数据同步；二是源同步时钟从全局时钟引脚进入FPGA且DCM做时钟反馈，保证数据与时钟相位关系。在实际工程设计中，设计者可以根据需求选择最佳设计方案。
　　[2] 于洋. 基于FPGA的高速传输接口的设计与实现[J]. 华中科技大学.
　　[3] 孙航. Xilinx 可编程逻辑器件的高级应用与设计技巧[M]. 电子工业出版社.

第一个问题：二者不一样，不是一回事。SRAM型fpga是指，片内的逻辑资源是跟SRAM类似结构的，配置过程就像写ram一样，掉电后消失，结构比SRAM复杂的多，所以每次上电都需要重配置。对应的另一种FPGA有flash型，结构单元和flash存储器一样，掉电不消失。

至于BLOCK ram是指FPGA内部嵌入有SRAM，用于存储数据的，就跟CPU 的Cache一样的。SRAM型FPGA的逻辑单元也可以用来做数据存储，速度快，布线效果更好，但是逻辑单元相当复杂远远超过了SRAM，成本非常高，所以FPGA才专门加入专用于数据缓存的SRAM块。

第二个问题：可以这样看认为，查找表是基本结构，FPGA内部没有存程序的SRAM，配置过程就是在配置逻辑单元。我觉得你最好先看看器件手册，比如常用的Cyclone IV你可以看看handbook中的Vol1.section 1,device core。

第三个问题：额这个。。这个能不能一概而论不好说。。。

阿里妹导读：X-Engine 是集团数据库事业部研发的新一代存储引擎，也是新一代分布式数据库X-DB的根基。在线事务处理的数据库存储引擎中，如何有效率的回收多版本的旧数据一直是一个难题，尤其在write intensive的应用中，事务处理无可避免受到后台任务的干扰(compaction or vacuum)，引入异构计算设备来offloading这些任务的想法由来已久，但是真正想要应用起来确有难度。

今天，我们将为大家详细介绍带有FPGA加速的X-Engine存储引擎。这篇文章不仅仅讲述如何设计并实现出更高效的FPGA逻辑，还有如何提升I/O，做好混合负载调度、容错等。"平稳"二字，看似波澜不惊，实则暗藏巨浪。

X-Engine 是集团数据库事业部研发的新一代存储引擎，是新一代分布式数据库X-DB的根基。为了达到10倍MySQL性能，1/10存储成本的目标，X-DB从一开始就使用了软硬件结合的设计思路， 以充分发挥当前软件和硬件领域最前沿的技术优势。而引入FPGA加速是我们在定制计算领域做出的第一个尝试。目前FPGA加速版本的X-DB已经在线上开始小规模灰度，在今年6.18，双11大促中，FPGA将助力X-DB， 将在不增加成本的前提下，满足阿里业务对数据库更高的性能要求。

作为世界上最大的在线交易网站，阿里巴巴的 OLTP （online transaction processing） 数据库系统需要满足高吞吐的业务需求。根据统计，每天 OLTP 数据库系统的记录写入量达到了几十亿，在2017年的双十一，系统的峰值吞吐达到了千万级TPS (transactions per second)。阿里巴巴的业务数据库系统主要有以下几个特点：

• 事务高吞吐并且读操作和写操作的低延时；

• 写操作占比相对较高，传统的数据库workload，读写比一般在 10:1 以上，而阿里巴巴的交易系统，在双十一当天读写比达到了 3:1；

• 数据访问热点比较集中，一条新写入的数据，在接下来7天内的访问次数占整体访问次数的99%，超过7天之后的被访问概率极低。

为了满足阿里的业务对性能和成本近乎苛刻的要求，我们重新设计开发了一个存储引擎称为X-Engine。在X-Engine中，我们引入了诸多数据库领域的前沿技术，包括高效的内存索引结构，写入异步流水线处理机制，内存数据库中使用的乐观并发控制等。

为了达到极致的写性能水平，并且方便分离冷热数据以实现分层存储，X-Engine借鉴了LSM-Tree的设计思想。其在内存中会维护多个 memtable，所有新写入的数据都会追加到 memtable ，而不是直接替换掉现有的记录。由于需要存储的数据量较大，将所有数据存储在内存中是不可能的。

当内存中的数据达到一定量之后，会flush到持久化存储中形成 SSTable。为了降低读操作的延时，X-Engine通过调度 compaction 任务来定期 compact持久化存储中的 SSTable，merge多个 SSTable 中的键值对，对于多版本的键值对只保留最新的一个版本（所有当前被事务引用的键值对版本也需要保留）。

根据数据访问的特点，X-Engine会将持久化数据分层，较为活跃的数据停留在较高的数据层，而相对不活跃(访问较少)的数据将会与底层数据进行合并，并存放在底层数据中，这些底层数据采用高度压缩的方式存储，并且会迁移到在容量较大，相对廉价的存储介质 (比如SATA HDD) 中，达到使用较低成本存储大量数据的目的。

如此分层存储带来一个新的问题：即整个系统必须频繁的进行compaction，写入量越大，Compaction的过程越频繁。而compaction是一个compare & merge的过程，非常消耗CPU和存储IO，在高吞吐的写入情形下，大量的compaction操作占用大量系统资源，必然带来整个系统性能断崖式下跌，对应用系统产生巨大影响。

而完全重新设计开发的X-Engine有着非常优越的多核扩展性，能达到非常高的性能，仅仅前台事务处理就几乎能完全消耗所有的CPU资源，其对资源的使用效率对比InnoDB,如下图所示：

在如此性能水平下，系统没有多余的计算资源进行compaction操作，否则将承受性能下跌的代价。

经测试，在 DbBench benchmark 的 write-only 场景下，系统会发生周期性的性能抖动，在 compaction 发生时，系统性能下跌超过40%，当 compaction 结束时，系统性能又恢复到正常水位。如下图所示：

但是如果 compaction 进行的不及时，多版本数据的累积又会严重影响读操作。

资源是无法避免的。据相关研究统计，在使用SSD存储设备时，系统中compaction的计算操作占据了60%的计算资源。因此，无论在软件层面针对 compaction 做了何种优化，对于所有基于 LSM-tree 的存储引擎而言，compaction造成的性能抖动都会是阿喀琉斯之踵。

幸运的是，专用硬件的出现为解决compaction导致的性能抖动提供了一个新的思路。实际上，使用专用硬件解决传统数据库的性能瓶颈已经成为了一个趋势，目前数据库中的select、where操作已经offload到FPGA上，而更为复杂的 group by 等操作也进行了相关的研究。但是目前的FPGA加速解决方案存在以下两点不足：

• 目前的加速方案基本上都是为SQL层设计，FPGA也通常放置在存储和host之间作为一个filter。虽然在FPGA加速OLAP系统方面已经有了许多尝试，但是对于OLTP系统而言，FPGA加速的设计仍然是一个挑战；

• 随着FPGA的芯片尺寸越来越小，FPGA内部的错误诸如单粒子翻转（SEU）正在成为FPGA可靠性的越来越大的威胁，对于单一芯片而言，发生内部错误的概率大概是3-5年，对于大规模的可用性系统，容错机制的设计显得尤为重要。

为了缓解compaction对X-Engine系统性能的影响，我们引入了异构硬件设备FPGA来代替CPU完成compaction操作，使系统整体性能维持在高水位并避免抖动，是存储引擎得以服务业务苛刻要求的关键。本文的贡献如下：

• 混合存储引擎的异步调度逻辑设计。由于一次FPGA compaction的链路请求在ms级别，使用传统的同步调度方式会阻塞大量的compaction线程并且带来很多线程切换的代价。通过异步调度，我们减少了线程切换的代价，提高了系统在工程方面的可用性。

• 容错机制的设计。由于输入数据的限制和FPGA内部错误，都会造成某个compaction 任务的回滚，为了保证数据的完整性，所有被FPGA回滚的任务都会由同等的CPU compaction线程再次执行。本文设计的容错机制达到了阿里实际的业务需求并且同时规避了FPGA内部的不稳定性。

X-Engine的存储结构包含了一个或多个内存缓冲区 （memtable）以及多层持久化存储 L0, L1, ... ，每一层由多个SSTable组成。

range的SSTable的合并，这个过程就叫做compaction。类似的，当一层的SSTable个数超过了阈值都会触发和下层数据的合并，通过这种方式，冷数据不断向下流动，而热数据则驻留在较高层上。

一个compaction过程merge一个指定范围的键值对，这个范围可能包含多个data block。一般来说，一个compaction过程会处理两个相邻层的data

对于读操作而言，X-Engine需要从所有的memtable中查找，如果没有找到，则需要在持久化存储中从高层向底层查找。因此，及时的compaction操作不仅会缩短读路径，也会节省存储空间，但是会抢夺系统的计算资源，造成性能抖动，这是X-Engien亟待解决的困境。

从现在的FPGA加速数据库现状分析，我们可以将FPGA加速数据库的架构分为两种，"bump-in-the-wire" 设计和混合设计架构。前期由于FPGA板卡的内存资源不够，前一种架构方式比较流行，FPGA被放置在存储和host的数据路径上，充当一个filter，这样设计的好处是数据的零拷贝，但是要求加速的操作是流式处理的一部分，设计方式不够灵活；

后一种设计方案则将FPGA当做一个协处理器，FPGA通过PCIe和host连接，数据通过DMA的方式进行传输，只要offload的操作计算足够密集，数据传输的代价是可以接受的。混合架构的设计允许更为灵活的offload方式，对于compaction这一复杂操作而言，FPGA和host之间数据的传输是必须的，所以在X-Engine中，我们的硬件加速采用了混合设计的架构。

在传统的基于LSM-tree的存储引擎中，CPU不仅要处理正常的用户请求，还要负责compaction任务的调度和执行，即对于compaction任务而言，CPU既是生产者，也是消费者，对于CPU-FPGA混合存储引擎而言，CPU只负责compaction任务的生产和调度，而compaction任务的实际执行，则被offload到专用硬件（FPGA）上。

对于X-Engine，正常用户请求的处理和其他基于LSM-tree的存储引擎类似：

1. 输入数据通过DMA传输到FPGA的DDR上；

• block中的，Decoder模块的主要作用是为了解码键值对。每一个CU内部放置了4个Decoder，CU最多支持4路的compaction，多余4路的compaction任务需要CPU进行拆分，根据评估，大部分的compaction都在4路以下。放置4个Decoder同样也是性能和硬件资源权衡的结果，和2个Decoder相比，我们增加了50%的硬件资源消耗，获得了3倍的性能提升。

流水线的最大挑战在于每一个步骤的执行时间差距很大。比如说由于并行化的原因，decode模块的吞吐远高于encoder模块，因此，我们需要暂停某些执行较快的模块，等待流水线的下游模块。为了匹配流水线中各个模块的吞吐差异，我们设计了controller模块去协调流水线中的不同步骤，这样设计带来的一个额外好处是解耦了流水线设计的各个模块，在工程实现中实现更敏捷的开发和维护。

从实验中我们可以得到以下三个结论：

• 随着key长度的增长，FPGA compaction的吞吐降低，这是由于需要比较的字节长度增加，增加了比较的代价；

• 加速比（FPGA throughput / CPU throughput）随着value长度的增加而增加，这是由于在KV长度较短时，各个模块之间需要频繁进行通信和状态检查，而这种开销和普通的流水线操作相比是非常昂贵的。

由于FPGA的一次链路请求在ms级别，因此使用传统的同步调度方式会造成较频繁的线程切换代价，针对FPGA的特点，我们重新设计了异步调度compaction的方式：CPU负责构建compaction task并将其压入Task Queue队列，通过维护一个线程池来分配compaction task到指定的CU上，当compaction结束后，compaction任务会被压入到Finished Queue队列，CPU会检查任务执行的状态，对于执行失败的任务会调度CPU的compaction线程再次执行。通过异步调度，CPU的线程切换代价大大减少。

• 数据在传输过程中被损坏，通过在传输前和传输后分别计算数据的CRC值，然后进行比对，如果两个CRC值不一致，则表明数据被损坏；

• FPGA本身的错误（比特位翻转），为了解决这个错误，我们为每一个CU配置了一个附加CU，两个CU的计算结果进行按位比对，不一致则说明发生了比特位翻转错误；

• compaction输入数据不合法，为了方便FPGA compaction的设计，我们对KV的长度进行了限制，超过限制的compaction任务都会被判定为非法任务。

对于所有出错的任务，CPU都会进行再次计算，确保数据的正确性。在上述的容错机制的下，我们解决了少量的超过限制的compaction任务并且规避了FPGA内部错误的风险。

我们比较两种存储引擎的性能：

• 由于FPGA compaction吞吐更高，更及时，因此读路径减少的更快，因此在读写混合的场景下X-Engine-FPGA的吞吐提高了50%；

• 读写混合场景的吞吐小于纯写场景，由于读操作的存在，存储在持久层的数据也会被访问，这就带来了I/O开销，从而影响了整体的吞吐性能；

• 两种性能曲线代表了两种不同的compaction状态，在左图，系统性能发生周期性的抖动，这说明compaction操作在和正常事务处理的线程竞争CPU资源；对于右图，X-Engine-CPU的性能一直稳定在低水位，表明compaction的速度小于写入速度，导致SSTable堆积，compaction任务持续在后台调度；

• 由于compaction的调度仍然由CPU执行，这也就解释了X-Engine-FPGA仍然存在抖动，并不是绝对的平滑。

• check unique的存在引入了读操作，随着压测时间的增长，读路径变长，因此两个存储引擎的性能随着时间下降；

• 在write-only场景下，X-Engine-FPGA的吞吐提高了40%，随着读写比的上升，FPGA Compaction的加速效果逐渐降低，这是因为读写比越高，写入压力越小，SSTable堆积的速度越慢，因此执行compaction的线程数减少，因此对于写密集的workload，X-Engine-FPGA的性能提升越明显；

• 随着读写比的上升，吞吐上升，由于写吞吐小于KV接口，因此cache miss的比例较低，避免了频繁的I/O操作，而随着写比例的上升，执行compaction线程数增加，因此降低了系统的吞吐能力。

• 通过FPGA加速，随着连接数从128增加到1024，X-Engine-FPGA可以得到10%~15%的性能提升。当连接数增加时，两个系统的吞吐都逐渐降低，原因在于随着连接数增多，热点行的锁竞争增加；

• TPC-C的读写比是1.8：1，从实验过程来看，在TPC-C benchmark下，80%以上的CPU都消耗在SQL解析和热点行的锁竞争上，实际的写入压力不会太大，通过实验观测，对于X-Engine-CPU系统，执行compaction操作的线程数不超过3个 （总共64核心），因此，FPGA的加速效果不如前几个实现明显。

• X-Engine-FPGA提高了40%以上的吞吐性能，由于SQL解析消耗了大量的CPU资源，DBMS的吞吐要小于KV接口；

• X-Engine-CPU在低水位达到了平衡，原因在于compaction的速度小于写入速度，导致SST文件堆积，compaction持续被调度；

• X-Engine-CPU的性能两倍于InnoDB，证明了基于LSM-tree的存储引擎在写密集场景下的优势；

• 和TPC-C benchmark相比，Sysbench更类似阿里的实际交易场景，对于交易系统而言，查询的类型大部分是插入和简单的点查询，很少涉及范围查询，热点行冲突的减少使得SQL层消耗的资源减少。在实验过程中，我们观测到对于X-Engine-CPU而言，超过15个线程都在执行compaction，因此FPGA加速带来的性能提升更加明显。

在本文中，我们提出的带有FPGA加速的X-Engine存储引擎，对于KV接口有着50%的性能提升，对于SQL接口获得了40%的性能提升。随着读写比的降低，FPGA加速的效果越明显，这也说明了FPGA compaction加速适用于写密集的workload，这和LSM-tree的设计初衷是一致的，另外，我们通过设计容错机制来规避FPGA本身的缺陷，最终形成了一个适用于阿里实际业务的高可用的CPU-FPGA混合存储引擎。

此项目是X-DB引入异构计算设备，以加速数据库核心功能的第一个落地项目。从使用经验来看，FPGA能完全解决X-Engine的Compaction带来的计算需求。同时我们也在进一步研究将更多合适的计算任务调度到FPGA上运行，如压缩，生成BloomFilter，SQL JOIN算子等。目前压缩功能开发基本完毕，将会和Compaction做成一套IP，同步完成数据合并和压缩操作。

X-DB FPGA-Compaction硬件加速，是数据库事业部数据库内核团队，服务器研发事业部定制计算团队，浙江大学三方合作完成的一个研发项目。同时此项目的落地也有赖Xilinx公司技术团队的大力支持，在此一并表示感谢。

X-DB将在今年上线阿里云进行公测，大家可以体验到FPGA加速给X-DB带来的极致性能，也期待大家的宝贵建议。

本文转载自阿里技术公众号，如涉及侵权，请私信小编删除。

想加入我们FPGA学习交流群吗？可以长按或扫描以下二维码，审核通过后我们邀请您加入。

这些微信群旨在打造一个提供给FPGA工程开发人员及兴趣爱好者（统称“FPGAer”）进行技术交流、答疑解惑和学习的平台。而且我们也将会通过网络举办FPGA技术讲座，分享相关研究文献。